[Mono-devel-list] Elegant cross-platform and cross-IDE build system for CIL projects

[Andrew Clunis]

Greetings all!

The CIL/.NET is a great system for writing clean, well-integrated,
standardized applications of many types quickly and painlessly on all
manner of different systems.  But one problem that seems to remain is
coming up with a clean, standard, friendly to multiple environments
method for organizing the source trees and build systems of our CIL
applications and libraries.

This is what is out there so far:

-- IDE specific build systems
  -- such as a VS.net solution/msbuild or MD/#D combine
  -- require the use of that particular IDE, or perhaps an 'importer' of
another IDE... definitely a case of YMMV on this one.
  -- no reasonable support for installation/packaging
  -- usually very environment specific

-- Environment Build systems
  -- GNU autotools and make
  -- Microsoft Make
  -- batch files and shell scripts
  -- goodness knows what else
  -- things usually hardwired (ie., expecting the compiler to be named
'mcs')
  -- usually terribly unfriendly to other environments!

-- prebuilders
  -- such as dnpb (http://dnpb.sf.net)
  -- generate project files for a host of IDEs and build tools
  -- does not actually build anything itself
  -- existing implementations do not include things like
installation/packaging metadata

-- agnostic build systems
  -- such as nant (http://nant.sf.net)
  -- like make, use a project metadata file and builds using that
  -- again, only limited support for installation/packaging metadata,
usually involving hacks
  -- nant itself has a broken build system, and the code is also
somewhat broken under mono


There are a plethora of problems common to .NET packaging in general:
-- binary dependencies included in source distributions (VERY BAD! For
both licensing and cleanliness).  msbuild even wants build instructions
to be in binary assemblies! ARGH
  -- sometimes even the build system tools (such as from the
"prebuilders" section above) are included!
  -- this issue is often provoked by the "Solution Items" facility of
Visual Studio
-- Developers who work primarily one environment but support the other
can find it hard to maintain concurrency with their build methods.
-- Source trees not arranged alike at all. Some have binaries in
src/bin, some in src/bin/<build mode>/, etc.  There should be a standard
method for managing the produced binaries, and producing a final binary
output directory.
-- many different projects have different build systems everything from
the prebuilders to Visual Studio Solutions (only windows friendly) to
GNU autotools (not well suited to .NET development, not very windows
friendly)

My take on requirements for a system that would mitigate these issues:
  -- Integration with the IDEs (MonoDevelop, Visual Studio,
SharpDevelop... etc.)
  -- Versatility without promoting ugliness.  Some projects, (I'm afraid
I do not have any examples at present) perform tricks such as compiling
an assembly normally, ildasm'ing it, modifying the IL, and then
rebuilding it.
  -- Proper functionality and solution metadata for actually installing
the project
  -- proper interaction with the GAC, for both compiling against
dependencies to installing
  -- integration with packagers (deb, rpm, gentoo ebuild, NSIS+mono,
NSIS+ms.net, etc.) would be awfully nice for maintainability.  The
solution files for this hypothetical system would contain all the
information necessary to create the input for the packagers, so why have
duplicate information?
  -- interoperability with all CIL implementations, with a minimum of
hardwiring stuff (and keeping solution files in a project from being
hardwired to one framework or another!)
  -- intelligent source packages that can easily be build on all systems
(same idea as the GNU classic ./configure && make && make install)
  -- Discouraging and mitigating the need for binary images, either
native or CIL in the source distribution of a project!
  -- Standardized source tree structure.  Current build systems throw
the resultant binaries in all manner of bin/ and /bin/Debug/
directories, and often require ugliness to properly get things to
compile and install.
  -- Hardwiring (absolute paths, tool usage, etc.) kept to a minimum in
projects' solution files
   -- ie, 'compile the C Sharp source files for module 'coolstuff' with
the resources miguel.png and bombs.txt (from the project resource store
of course!) as an assembly named "coolstuff.dll" as type library and
stow it in the project binary output directory' versus 'mcs
-out:"../../../.././bin/Solution
Items/../../even_more/.././../../../lib/bin/../../coolstuff.dll"
-target:library -resource:"../../pictures/miguel.png"
-resource:"../.././help/bombs.txt" *.cs'
  -- Elegance! A minimum of hackiness!


A few ideas I have how such a system could be achieved:
-- There has been talk recently of changing MonoDevelop's project format
to be more feature rich.  Perhaps we could add things like installation
metadata, etc. as described above and VS.net export functionality,
common binary dirs, etc. Update jluke's build tool, add vs.net export to
it, and perhaps stick a quick SWF GUI on it to allow Windows users easy
access.  The downside would be that we would no longer have the same
project format as SharpDevelop, but this may well be inevitable anyway.
-- Soup up one of the (pre)builders such as nant or dnpb to meet these
requirements.  Nant already seems mostly there and is just is missing a
few notable things like installation/packager and IDE integration.

So, hopefully this got some juices flowing!  So, post your thoughts!
Post! :D

Should I create a page on the mono wiki?

-- 
Regards,
Andrew Clunis

http://orospakr.is-a-geek.org/