I've been trying to put together a non-recursive build system and ran into
the fact that gmake's "include" directive is always relative to the CWD.
This isn't how cpp does things, and is unexpected behavior to say the least.
Is there some unavoidable reason why relative includes aren't relative to
the including Makefile (and not the original make invocation's CWD)?
Here's a simple example:
top/Makefile:
> test:
> @echo $(MAKEFILE_LIST)
top/a/Makefile:
> include ../Makefile
top/a/b/Makefile:
> include ../Makefile
Doing "make test" in top/a/b will fail because top/a/Makefile recursively
includes
itself instead of including top/Makefile. Compare with cpp:
top/t.c:
> #include <stdio.h>
> int main( int argc, char *argv[] ) { printf( "Works!\n" ); return 0; }
top/a/t.c:
> #include "../t.c"
top/a/b/t.c:
> #include "../t.c"
gcc -o t t.c from top/a/b works as expected.
I think changing gmake's behavior to match cpp's will eliminate the need for a
lot
of hacky farting around to get non-recursive systems working smoothly. An
important
design consideration is keeping the complexity out of the leaf Makefiles so it
would
be nice not to have to have boiler plate lines like:
include $(addprefix ../,$(lastword $(MAKEFILE_LIST)))
It would also eliminate the need for new built-in variables
(see http://savannah.gnu.org/bugs/?35485)
Are we locked into a bad design decision at this point, or can this be fixed?
I should note that I've built a lot of recursive build systems (including very
large
and complicated ones for million+ line projects) and I've always assumed the
include
directive worked the way I expected, so I don't see offhand what would break
for recursive builds. Non-recursive builds would probably welcome the chance
to make things simpler (and they seem to be rarer than recursive builds still).
A possible solution might be to do the expected thing by default and fall back
to
CWD-relative includes if the Makefile-relative target doesn't exist? Adding a
command-line option isn't great (users should just be able to type "make" and
have it work).
- Ed
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
