Re: include ... why not search in same directory ?

[Markus Mauhart]

"Paul D. Smith" <address@hidden> wrote ...
>
> Add this to the top of your makefile (maybe in a general included
> makefile):
>
>   __FILE__ := $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST))
>
> Then just use __FILE__ from then on.

This has major problems when compared with what one would expect
from something called __FILE__.

0) 1st a no-problem: when other parent/child include files or variables from
the command line or from the environment use the name __FILE__ with another
semantic in mind, then nothing helps - but this is the same for all
variable names.

1) IMHO __FILE__ should be recursively expanded (like MAKEFILE_LIST).

2) take a couple of makefiles, connected via include, more than one of them
using __FILE__ with same semantic. Consider only the ones using __FILE__.
Then each of them at its top has to save __FILE__'s old value using
a variable with unique name, then compute __FILE__'s new value from
MAKEFILE_LIST. At the end of the makefile, restore __FILE__.
Computing the unique name (-> must convert __FILE__'s new value into a valid
variable name). All in all this is much more than a single line on top
of the makefile, it is not easy, it is easily done wrong, it will blow
up simple makefile-include's, it has to be parsed and then to be ignored
by every human makefile-reader; so IMHO this not-builtin solution is
really expensive w.r.t. human resources.


Btw, just found AFAICS undocumented behaviour of make:

//------------------
__FILE__ = $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST))
__FILE_DIR__ = $(dir $(__FILE__))

#adjust VPATH --> this has the expected effect.
VPATH += $(__FILE_DIR__)

#adjust MAKEFLAGS --> this has not the expected effect;
#allthough MAKEFLAGS gets changed, the change is not used
#when searching for include files.
override MAKEFLAGS += -I $(__FILE_DIR__)

include default.mak #from same dir.
//------------------

W.r.t. MAKEFLAGS the docu says:
(1) "The options `-C', `-f', `-o', and `-W' are not put into MAKEFLAGS;"
(2) "these options are not passed down."

Shouldnt (1) have added "-I" ?
W.r.t. (2), are options of category (1) that are manually added to MAKEFLAGS
passed down to sub-makes ?
Are "-I" from the command line passed down to submakes by some
other magic (independent from MAKEFLAGS) ?
Shouldnt make report an (documented) error when unsupported
options are manually added to MAKEFLAGS ?


>   >> , then no.  This behavior has been around forever and make is too basic
>   >> a tool to introduce these kinds of major incompatibilities with previous
>   >> versions.
>
>   mm> Understandable; allthough I'm not convinced that this fix of a
>   mm> mis-feature would have to introduce more major incompatibilities
>   mm> than many other changes that happened through make's history.
>
> Like what?  There is virtually _never_ a change which is not
> backward-compatible. Possibly some changes might not be backward
> compatible if you're using very bizarre types of syntax, like filenames
> consisting of nothing but the character "|" or similar.

No, I wouldnt blame a tool for breaking really bizar usage.

> Were you thinking of something in particular?

Yes, I thought of built-in variables that have been added sometimes (dont
know exactly when): CURDIR, MAKEFILE_LIST, ... Each existing makefile using
that variable names then was broken. Otherwise it would be easy to add
a new built-in variable with __FILE__ semantic ;-)

> In one of my build systems right now, for example, each directory has a

breaking one of your current systems is really bad luck for my request ;-)

> special makefile "local.mk" that describes that directory.  When make is
> invoked it is run like this:
>
>   make -f $(TOPDIR)/mk/master.mk
>
> and inside the master.mk file it includes "local.mk".  This works
> because it searches the current working directory even though the
> master.mk file is not local.

So also your $(TOPDIR)/mk/ contains a file local.mk ?
But you have to agree that this required(!) precondition of making
make's CURDIR equal to its current source dir looks a bit strange
when compared to your golden rules ...

"3. Life is simplest if the targets are built in the current working directory."
"VPATH was designed to find sources, not targets."

... which I then summarized into: Start make from anywhere, create the
working directory, then restart make inside the working directory.


Now I assume you are right that the hidden include-search-change
I suggested is too visible.

I just found that make-3.80 doesnt accept 'include "filename"'; so am
I right that a syntax-extension for such quoted filenames could implement
the search-algorithm I want (or better: exactly like CPP) without breaking
existing makefiles (except for bizar filenames like "has_quotes") ?

Or could one use VPATH or vpath ? Just tried it, no chance:

//a makefile trying to include "default.mak" from its own directory:
VPATH += $(__FILE_DIR__)
vpath %.mak $(__FILE_DIR__)

.PHONY: all

all: default.mak ;

include default.mak


Regards,
Markus.