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

[Robin Farine]

>>>>> "MJ" == MJ Ray <address@hidden> writes:

    MJ> On 2003-09-18 04:55:13 +0100 Doran Moppert
    MJ> <address@hidden> wrote:
    >> funny how better-designed tools get both support and resistance from
    >> the same
    >> people in different contexts :). Not that I can talk -- I still use
    >> Make [...]

    MJ> I have problems understanding why people consider alternatives like
    MJ> cons and scons better designed.

Make doesn't allow one to create individual components that perform
well defined tasks while encapsulating the details. In some ways, it
makes me recall some Basic variants with their huge set of functions
falling from nowhere: "PrintHelloToScreen, PrintGoodByeToScreen", hey
boss, shouldn't we add "PrintHelloToInkJetPrinterHPxyz" for
completeness?

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. Look in detail in the glibc build system for a good
example. Yes, it's using recursive make calls but building this thing
without recursion is left as an exercise to the make guru out there.

SCons is based on a simple but structured programming language. It
provides clean abstractions for dependency generators, builders and a
few others. 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.

Also, almost everybody knows that human brains can only handle a small
number of interactions at the same time. When we observe something, we
always consider most of its parts with a highly abstract point of view
while we concentrate on the internal details of one small part. My
feeling is that in the build systems arena, tools like SCons let's do
this better than make.

    MJ> When all's said and done, Make actually seems capable of doing what it
    MJ> sets out to do: constuct dependency graphs and figure out a solution
    MJ> for the requested target based on certain information.  It's also
    MJ> capable of being used in a way that prevents it doing that properly
    MJ> (recursive make fans, are you listening?) but you can break most tools
    MJ> if you try hard enough.

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

So, SCons does not at all qualify as the panacea in its domain but I
consider it as a progress compared to make.

    MJ> The only alternative that I've seen which seems to offer benefits is
    MJ> cook.  Even those benefits (faster graph construction/solution and
    MJ> more human-friendly syntax) may not be worth the cost of using it for
    MJ> small projects.  Cook is quite badly promoted, too: why on earth is
    MJ> the manual not obviously online as nice HTML?  Cue another
    MJ> documentation tools thread...

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.

-- 
rnf