[Mono-list] Mono Tools and Utilities

[Jonathan Pryor]

I'm not sure that autoconf/automake is a good match for C#.

Though if we went that route, supporting "make distcheck" would become
trivial. ;-)  (Ignore this unless you read cvs-list...)

I'm primarily after something that would be fairly easy to support.  I
need to minimize the work required on my part, as I only have a few
hours a week, and most of that goes toward email.  This is likely true
for many people.

So there are five possible build systems I see that could be used for
mono-tools:

	1.  autoconf/automake: usable, but likely more complicated than
	    it needs to be.

	    However, if we want to add a lot of code that already makes 
	    use of autoconf/automake, it may be sensible to just make
	    everything use autoconf/automake.  (There is already support
	    in mono-tools to support a hybrid autoconf & Makefile
	    system.)

	2.  NAnt: It exists, and people are familiar with it, but little
	    (if any) of the existing Mono code uses it.

	    Furthermore, with the performance issues that were noted
	    last week, it's not an ideal solution now.  That may change
	    soon, though.

	3.  New build tool: Might be nice, but no one has time to work
	    on such a thing right now.  Probably not worth waiting for.

	4.  Use the existing mcs/build scripts: This was my initial
	    idea.

	    Pros: it exists and works.  Cons: Might be too complicated
	    for long term support.

	5.  Write a new set of Makefiles: Requires writing new scripts.

At present a mix of (1) and (5) is in use (autoconf is used, and will
search subdirectories for configure scripts to run at configure time,
and type-reflector has it's own Makefile system).

Furthermore, following (4) would allow programs already in mcs/tools
(such as SqlSharp and security/certview) to be moved with minimal/no
changes to their Makefiles.

The question is, what should be adopted for long-term development use.

Suggestions?  Opinions?

 - Jon

On Sun, 2003-10-12 at 15:15, Peter Williams wrote:
> Hi Jon,
> 
> On Sun, 2003-10-12 at 10:59, Jonathan Pryor wrote:
> > So I would also propose the following:
> > 
> > 	1.  Move mcs/build into a new CVS repository, "build"
> > 	2.  Use the CVS aliasing functionality [1] to insert the "build"
> > 	    CVS repository into the "mcs" and "mono-tools" repositories.
> > 	    This would allow the build system to be located in one
> > 	    location, and all users would receive updates
> > 	    simultaneously.
> 
> As the guy who wrote most of the build system, I'm not sure if this is
> the best idea, although the build system is so low-maintenance that I
> don't think moving it would be a huge problem. My reasons are:
> 
> 	* A lot of the build system is about supporting *complex* 
> 	  cross-platform compilations: of corlib, with large source
> 	  trees, with interdependent libraries, etc. I suspect 
> 	  mono-tools' needs would be simpler, and could probably be
> 	  met with a much smaller set of Makefile code
> 
> 	* Trying to implement a nontrivial build with make is just so
> 	  much more of a hassle than it should be. On the other hand,
> 	  I think nant has many bad design decisions, and although I
> 	  have an (IMHO) awesome idea and basic framework for a C# 
> 	  build tool, I (of course) have ~0 free time to work on it.
> 
> 	* This is relatively minor, but if more projects start using
> 	  the build/ files, then they *will* become high maintenance,
> 	  and if people are going to spend time on a build system, I'd
> 	  much rather it be on implementing a better one, rather than
> 	  working within the confines of pure make.
> 
> Anyway, if you want to alias the build/ stuff, I'm not against it, I'm
> just not totally encouraging it. My feeling is it might be easiest and
> sanest just to bolt into autoconf/automake as best you can.
> 
> 	Peter