RE: [Gnu-arch-users] Re: [going OT] build tool design, was: tlato r-0.1 initial release

[Bill Petheram]

> -----Original Message-----
> From: MJ Ray [mailto:address@hidden
> Sent: 18 September 2003 15:27
> To: address@hidden
> Subject: Re: [Gnu-arch-users] Re: [going OT] build tool design, was:
> tlator-0.1 initial release
> 
> 
> On 2003-09-18 14:44:25 +0100 Robin Farine <address@hidden> 
> wrote:
> > Make doesn't allow one to create individual components that perform
> > well defined tasks while encapsulating the details.
> 
> I don't understand what you mean by this.  Make is a component that 
> performs a well-defined task (building targets) while encapsulating 
> the details of its rules, isn't it?  Make allows you to create other 
> components to do that and other tasks.  It just exists and 
> doesn't run 
> around using rm on scons if it finds it.
> 

I understand him to mean that make is not good at handling multi directory
builds. Certainly dependencies across directories is difficult. For these
complex projects you have to use imake or automake. But then again I haven't
seen any build system that handles large complex projects in a good way.

> > In a complex enough project, the makefiles become such a big pile of
> > rules and variables, one hardly knows where a variable will change,
> > where it will be expanded, if a name is free or already used
> > somewhere.
> 
> Remember, I did admit that it is possible to use make badly.  People 
> see complicated Makefiles and feel that they should be making 
> complicated ones as part of some dick size war, even when a simpler 
> one would do.  There's also the normal project problems of organic 
> growth and so on.
> 
> I suspect that it is possible to use SCons badly, especially given 
> that its build rules appear to be written in an imperative 
> programming 
> language.  There may be cases where SCons offers extra benefits, but 
> again, I cannot translate your message into obvious benefits.  It may 
> be that SCons jargon is new to me.  As far as I can tell, this:
> 
> > When one need a builder not part of the standard set,
> > SCons makes it easy to create it, and independently from the builder
> > complexity, one can isolate its implementation so that it does not
> > have undesired effects on the rest of the system.
> 
> ...just means that you can write new rules to build files and one 
> build rule does not have undesired effects on others.  Good uses of 
> Make have the same properties, for the same reasons about 
> interactions 
> as you gave.  I am not sure how often a truly tortuous build process 
> is required and I'm not sure how writing Python is better at it.
> 
> > Well, Cobol was already capable of handling records and fields and
> > performing computations but we always feel the need to try different
> > ways of doing one thing, so new languages/tools appeared since then.
> > Sometimes it works better, sometimes it doesn't. But after a 
> > sufficient
> > amount of time has elapsed, we look backward and notice a 
> "progress".
> 
> Well, Cobol was a backwards step from the pre-existing Lisp.  I'm 
> still not sure whether we can look back over much progress in the 
> field of languages in general, or just better understanding of the 
> problems that Lisps have already solved and better tools for Lisps.
> 
> Maybe SCons offers some benefit over Make, but I have trouble seeing 
> it.  I can see the problems it brings clearly, with every Tom 
> Dick and 
> Harry defining their own procedures that have to be 
> understood to work 
> out exactly what the build system is doing.  (I'll refrain from the 
> normal "Python half-OO" diatribe.)
> 
> [...]
> > Not absolutely sure about cook but I seem to recall it relies on a 
> > lot of
> > axioms and a few derived constructs, generally not a sign 
> of powerful
> > simplicity.
> 
> I think the same can be said of the choice to put a whole programming 
> language interpreter inside the build tool, but there you go.
> 

This presents an intersting problem. Make has programming constructs added
to it. ant for example explicitely does not have any programming constructs.
This to my mind can make building larger projects difficult.

I am currently using Maven, which is fine for java projects.