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
_______________________________________________
Bug-make mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-make
