Re: suddenly, "recursive make considered harmful" makes piles ofsense

[Noel Yap]

Alessandro Vesely wrote:

> Noel Yap wrote:
>
> > IME, it's best to have a GNUmakefile in each directory (so anyone can do a gmake
> > within any directory) and a, say, GNUprivate.mk file within each directory (that
> > contains the non-common stuff).
>
> The problem of recursing becomes apparent when there are inter-directory
> dependencies. Did you ever wish, while writing a makefile, that you had
> at hand all the dependencies already specified for another directory?
> In facts, writing recursively is easier and there is much more experience
> with it than with single makefile builds.

IME, inter-directory dependencies can be handled with non-recursive make.  In 
fact, it's handled better than with recursive make.

IMHO, no amount of expertise can fix broken dependency graphs due to a broken 
infrastructure.

> > I've seen two philosophies on this:
> > 1. gmake within any directory will build the entire project
> > 2. gmake within any directory will build that directory and
> > any subdirectories (a la recursive make)
> >
> > I personally lean towards the second philosophy
>
> me too.
>
> > which means that each GNUmakefile needs to include its corresponding
> > GNUprivate.mk and its subdirectories' GNUprivate.mk's.
>
> AFAIK, there is no recognized standard for writing these.

Right.  The recognized standard uses recursive make which is broken.  One will 
either conform to the standard with all its drawbacks or forge with something 
that works completely and correctly.

> Of course there
> must be agreed variable naming conventions. However, should one code
> each file name with a variable prefix in front of it? E.g.,
>
>    TARGETS += $(PATH_TO_HERE)my_target
>    $(PATH_TO_HERE)my_target : $(PATH_TO_HERE)my_obj1 $(PATH_TO_HERE)my_obj2
>
> where PATH_TO_HERE is set to "this_subdir/" by the parent, or else is empty.
> That contradicts rules 3 and 4 in <http://make.paulandlesley.org/rules.html>,
> but there are no directives such as `include_and_cd' or even just `cd'.

In a non-recursive make, there is no cd.

> There is vpath, but how do I know that a source file named just like mine
> will never appear in some upper directory? Furthermore, many rules work
> just smoothly when issued from the proper directory. I often write
> `$(MAKE) -C' when all I wanted to say was `cd'.

I've been able to resolve all the issues you mention using creative uses of 
eval and user functions.  It takes time to come up with such an infrastructure 
because, as you say, expertise isn't widespread.

> > To minimize maintenance on GNUmakefile, a function is used that'll just
> > shell out and execute a "find . -name GNUprivate.mk".
>
> Otherwise, each GNUprivate.mk may include its subdirectories' GNUprivate.mk's.
> The $(wildcard) fuction may come handy for this.

Such functionality is common and so would be better left in the GNUmakefile 
rather than copied in each GNUprivate.mk.

In the end, ideally, all GNUprivate.mk would contain is a list of sources in the current directory, the list of goals (eg leaf targets) derived from the sources, and possibly one function call to provide the mapping from one to the other.  Rules may be 
used for this last part but IME calling use functions is a more general solution than using rules (eg calling user functions may create rules on the fly).

Noel