Re: non recursive makefiles

[MJ Ray]

Nicola Pero <nicola@brainstorm.co.uk> wrote:
> 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.