Re: non recursive makefiles

[Nicola Pero]

> > Recursive invocations and a GNUmakefile in every directory have a big
> > advantage -- that if you have a project containing many libraries and
> > tools in different directories, you can either type 'make' top level and
> > that will build everything, or you just go into a specific directory and
> > type 'make' there and that will only build the stuff in that specific
> > directory (which is lot faster).
> 
> Surely the same advantages can be had with targets that only build a
> subset of the project? Also, you could easily take one library out of
> the group if the GNUmakefile is broken into subfiles that are combined
> by sourcing or whatever. Refactoring into cohesive parts is good,
> while monolithic combination of irrelevant bits is bad, isn't it?
> 
> The main speed-up would be (IIRC) because make constructs a directed
> graph, then figures out what needs to be built and the right order to
> do it.  If the makefile is split up across recursive invocations, the
> first make can't "see" the directed graphs of the subdirectories and so
> has to visit directories in order just to check. This is also why -j
> sometimes fails, I think. Recursive make seems less modular because the
> modules are never combined. They just stand alone. It seems like the
> difference between a library and calling another command.
> 
> So, given the concepts driving make, it seems like the recursive design
> of gnustep-make conflicts with it, rather than being natural.  It may
> be a lot of work to change so the developers won't do it any time soon,
> but if someone has a few spare man-months lying around, I don't understand
> the vague design objections given so far.

Thanks, MJ Ray -- your comments make a good point -- the main problem is
that 'make' does not provide you with a full-fledged programming language.

It definitely doesn't.

It's extremely limited and we're already pushing it over the edge.  The
first obvious objection is that if you remove recursive invocations and
just include everything in the top-level GNUmakefile, then everything
defined in any GNUmakefile included by the top-level execution would be in
the same namespace.

For example, clearly you then can't have TOOL_NAME = xxx in two separate
GNUmakefiles because one's definition would override the other one.  So OK
you could change all GNUmakefiles on the planet to use 'TOOL_NAME += xxx'.  
But what about ADDITIONAL_OBJCFLAGS or similar variables ?  Compilation
flags for all GNUmakefiles would be in the same namespace.

So any GNUmakefile would have to use some sort of local namespace to avoid
conflicts, then the gnustep-make machinery would have to be aware of that
and try to make some sense out of it.  As local namespaces don't exist,
this would need to be implemented in some hackish way like you start your
GNUmakefile with 'NAMESPACE += Nicola' and then you prefix every variable
in the makefile with 'Nicola' (which I think is really clumsy because then 
it makes more difficult to copy GNUmakefiles across projects)

And then you mix it with the (currently available) ability to define
custom rules and extend the GNUmakefiles in various way and with the large
amount of variables and options...

And then you mix it with the fact that make doesn't allow you to iterate,
has very limited if/then/else support, has a global namespace for
variables and rules, and every single line of gnustep-make becomes a
potential nightmare to implement if every options for every GNUmakefile is
loaded at the same time ... where we currently do something like 'ifeq
($option, "yyy") / do something / fi' you have to iterate over all the
multiple values of $option defined in the various makefiles and execute
different code for each makefile ... only you can't iterate in make! and
while I can think of case-by-case tweaks which can let you work around it
in some specific cases, it gives you unreadable code so you only want to
use it as a last resort - if all the package was written that way it would
be some complicated, buggy and unreadable that nobody would use it

The complexity of just managing variables and rules for all the makefiles
in a single go is so huge that it would make the whole gnustep-make code
unmaintainable.  Never mind the fact I don't think it could be done with
an easy, intuitive GNUmakefile syntax.

So the reason why we have a separate sub-make invocation for each
GNUmakefile is to isolate each sub-make invocation so that it executes in
its sand-box and you can have a standard set of variables and rules you
can use in your GNUmakefile, and the complexity of gnustep-make is kept at
a reasonable level.  In each sandbox we just execute that iteration, have
all our local variables and rules and code executed in the "local context"
and the code is easy and readable.

NB: I'm often told that it's current implementation is already too complex
and that most people can't figure out how the internals work -- reason
being we are pushing the make language a bit to get all the features we
need.  If we did it without sandboxing each sub-make invocation it would
be a much bigger mess.  I just don't think it would be possible in any
reasonable timescale; it would take less time to write a make replacement
from scratch and use it.

Thanks, I hope that does explain a bit more why gnustep-make is the way it
is. :-)