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

[Andrew Clunis]

On Fri, 2004-07-09 at 00:04, Ian MacLean wrote:

> can you please explain what you mean by installation/packaging
metadata 
> in this context and detail what hacks you are referring to ?
> 
hm, I am sorry if I was not clear enough.  Essentially, the build files
would describe not only the source configuration of the project, but
would also describe deployment.  For instance, the configuration
information for assembly x would not only describe its build process,
but also define the ultimate deployment configuration, such as placing
it in the GAC, or the project's binary directory.  An external resource,
such as muzak.ogg, could be flagged with "install in project's data
directory.  Also, it could indicate where to place icons in the target's
graphical menu.

The build tool could then infer from this how to construct input file(s)
for the packagers/installers I mentioned.  Target locations specific to
the packager/installer and target system type would be automatically
determined by the build tool, for example:

On Unix, it could be:
bin dir: /usr/share/dotnet/<projectname>/bin
lib dir: /usr/share/dotnet/<projectname>/lib
data dir: /usr/share/dotnet/<projectname>/data
perhaps generate and install a simple shellscript in /usr/bin to launch
the app, etc.

On Windows, it could be:
bin dir: "c:/Program Files/<projectname>/bin"
lib dir: "c:/Program Files/<projectname>/lib"
data dir: "c:/Program Files/<projectname>/data"

The dpkg target could create the debian/ directory (ok, ok, I forget the
specifics of dpkg... :/ ), etc., and use the "graphical menu entry"
metadata I described above to create debian menu entries.

The rpm target could create the specfile.  Same with NSIS, just emit the
script.

Anyway, that is all very hypothetical of course, but that is just my
take on all the things the build tool could take care of to improve
maintainability and ease of deployment of projects for a variety of
different systems.

As for hackiness in existing systems, I refer to hard coded parameters
that refer to the system, not the project, but within the project.  Why
should it be the project's business to know how the host is arranged,
outside of the managed environment?  (ie, doing stuff like 'install
--mode=755 bin/MyApp.exe /usr/bin/MyApp.exe' in a Makefile)

> >  -- nant itself has a broken build system, and the code is also
> >somewhat broken under mono
> >  
> >
> How is the nant build system broken ?
> Our latest cvs builds and runs fine on Mono 1.0. Some of our unit
tests 
> are failing on mono its true but we're working thru those now logging 
> mono/ms.net incompatibility bugs where appropriate.

Really? Awesome, I'm glad to hear it!  Last time I used nant (on mono
0.9x last week or so), there were nasty issues with both CVS and the
tarballs, with dependencies included in the source tree, a load of
warnings during build, etc.

Anyway, I apologize for the mess of spelling and semantical errors in my
previous posting. Gah.  Too much pasting around and not enough
proofreading... 
-- 
Regards,
Andrew Clunis

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