bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: include should be relative to current Makefile


From: Ed H
Subject: Re: include should be relative to current Makefile
Date: Tue, 15 May 2012 09:38:58 -0700 (PDT)




By the same logic, one can use a (module-specific) variable meaning
"here" in each sub-directory's make-file fragments; so foo/config.mk
refers to its source files as $(FOOSRC)/bar.c and so on, rather than
assuming FOOSRC=. (although that likely remains the ?= setting in
foo/Makefile, for use when building just foo).  You can then equally
include $(FOOSRC)/baz/config.mk as long as you first set BAZSRC to
$(FOOSRC)/baz so that it knows where *its* "here" is, and so on.  (Of
course, if you have two copies of baz in use by different contexts, it's
going to get weirder; but that was going to be a problem any way you
like to come at it.)  For out-of-source building, you also need parallel
FOOOUT and BAZOUT variables, of course.  Note that you need these
variables to get the commands and rules right, so I don't really see a
strong case for getting rid of the need for them when including
makefiles.

So, while the include structure in make files is a pain to re-work
during converting from recursive make, it's really just another example
of how you have to re-work the rest of the make-file's content; so I'm
not persuaded that the (tempting) case for making the inclusion easier
is actually compelling.  It wouldn't solve the matching problems for
source lists and command-lines, after all.

       Eddy.
Thanks for the reply. I should point out I'm talking specifically about how
include works, not how the rest of the rule processing etc. works. I'd
suggest that the compelling argument for change is that leaf Makefiles are
the things people of various skill levels on the team actually interact with,
and assuming include worked the way I had expected it to work they could
remain fairly vanilla. E.g.:

ifndef TOP

include ../Makefile

else

SUBDIRS = <yadda yadda>
TARGETS = <list of things>
SRCS = <etc etc>

endif

All of the complexity you allude to can be safely buried in the TOP-level
Makefiles, leaving most users blissfully unaware of how the sausage is made.
Another idea I had for a solution is to add yet another directive, possibly
something like:

.include ../Makefile

(dot-include is a mnemonic for "include relative to here").

  - Ed


reply via email to

[Prev in Thread] Current Thread [Next in Thread]