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

[MJ Ray]

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.

> 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.

--
MJR/slef     My Opinion Only and possibly not of any group I know.
http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ address@hidden
 Creative copyleft computing services via http://www.ttllp.co.uk/