Re: how to define a set of targets for a recursive structure?

[Noel Yap]

"Robert P. J. Day" wrote:
> > Within the top-level makefile, you'd do something like:
> >
> > -include $(addsuffix /GNUbuild.mk.mk,$(TARGETS))
> 
> i have one concern with the above (at least, if i read it correctly).
> this looks like the technique used in the 2.4 kernel top-level makefile,
> which has the line:
> 
>   include arch/$(ARCH)/Makefile    # ARCH=ppc for example
> 
> which contains a rule for how to build the "vmlinux" target.  fair enough,
> but the problem with this direct inclusion is that that lower-level
> makefile has to continue to refer to files relative to the top level, so
> it's full of "arch/ppc/this" and "arch/ppc/that" references.

In my implementation, I use a function that sets the macro __FILE__ to be the 
file being included.

This allows me to do something like:

# ./GNUmakefile
$(call include-makefile,path/to/GNUbuild.mk)

# path/to/GNUbuild.mk
# $(dir $(__FILE__)) is equal to "path/to/"

Also, typically, lower level makefiles should know nothing about upper level 
makefiles.

Here's a snippet of what I have:
# GNUcommon.mk
$(call include-makefile,$(call find-down,GNUprivate.mk))        # includes 
`find . -name GNUprivate.mk`

# GNUmakefile
include GNUcommon.mk

# lib/GNUmakefile
include ../GNUcommon.mk

# lib/l1/GNUmakefile
include ../../../GNUcommon.mk

# lib/l1/GNUdependencies.mk
ifndef $(__FILE__)
$(__FILE__) := 1

$(__FILE__).dependencies := \
        lib/l0

$(__FILE__)!returns := $(__FILE__).dependencies

endif


Of course, there's a lot of magic and glue that puts this all together, but 
it's way too much to post here.  IME, if you go down the road of recursive 
makefiles (rather than recursive make), you'll discover for yourself what 
you'll need in order to reuse
and generalize your makefiles.

>   this strikes me as somewhat cumbersome -- designing a Makefile for the
> arch/ppc directory, and knowing it will be included from above which means
> i have to keep qualifying everything with "arch/ppc" -- something a
> recursive makefile wouldn't have to do.

An alternative is to use macros.

Another alternative, which I haven't yet tried but plan to to some extent, is 
described at http://make.paulandlesley.org/multi-arch.html.

>   wouldn't the approach you suggest here have the same issue?  i'm
> finally getting the time to start going over that paper by miller, so
> we'll see if i misunderstood this, but i don't see how you could avoid
> it.

I haven't found a way to avoid it completely.  OTOH, it doesn't bother me as 
much as it seems to bother you.  IMHO, explicitly stating the paths (via 
hard-coding or macros) makes the makefiles much easier to read since it's very 
clear what rule will get
triggered for what target.

I think recursive makefiles is a huge mindshift given that the rest of the 
world has been using recursive make for so long.  With that said, I suggest 
starting out small and simple (with possibly lots of redundant code), then 
iteratively refactoring and
enhancing as you gain more understanding of what's going on -- I didn't create 
my infrastucture overnight and I'm still making enhancements.

Now that I think about it, getting up and running with recursive make may be 
much quicker than with recursive makefiles, but in the long run, recursive 
makefiles is more robust in that it's better able to create complete dependency 
DAG's.

HTH,
Noel
-- 
NOTICE: If received in error, please destroy and notify sender.  Sender does 
not waive confidentiality or privilege, and use is prohibited.