Suggestion/Offer: new rinclude directive

[Luke Shumaker]

I had an idea for a feature that I believe will allow more elegant
multi-directory Makefiles to be written.

An alternate include directive, rinclude' (for relative include) that
treats all targets described in the included makefile as relative to the
included path.

[ Note: in this email, code samples are bracketed in <<<...>>> ]

So in my main Makefile, I can have
<<<
foo.out: foo/bar
>>>
Where bar foo/bar does not exist, and is not described in the Makefile.
However, I
<<<
rinclude foo/Makefile
>>>
which does describe bar, but without the `foo/'.  However, since I used
rinclude, all the targets (and dependencies) have `foo/' prefixed to
them.

Of course, there are other considerations, such as if the
target/dependency is an absolute filename.

Currently, this can be emulated two ways, by using recursive make:
<<<
rinclude = $1/%:$1/Makefile; $(MAKE) -C '$1' '$*'
>>>
and is used:
<<<
$(call rinclude,mysubdir)
>>>
Using this method, issues can arise with parallelization.  The
alternative is by using include, and prefixing all targets/dependencies
with a variable that stores the current directory:

<<<
ifndef THISFILE
THISFILE=$(CURDIR)/Makefile
endif
THISDIR=$(patsubst %/,%,$(dir $(THISFILE)))
rinclude=$(foreach THISFILE,$(abspath $1),\
$(eval include $(THISFILE)))
>>>
and is used:
<<<
$(call rinclude,mysubdir)
$(THISDIR)/all:
        ...
>>>
Which creates precisely the desired behavior, but requires you to muck
up your Makefiles by prefixing everything with `$(THISDIR)/'.

Further, it might be desirable to have to two implementations, one where
variables in the included file get passed back to the main file,
following normal include behavior; and one where they are ignored, as
the recursive option above does.  The benefit of separating them is that
it would allow a component that was not designed with this feature in
mind to be incorporated into a larger system without modification.

If you think this feature would be a good addition to GNU Make, I would
be willing to implement it.

-- 
~ LukeShu
http://lukeshu.ath.cx