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

[Markus Mauhart]

"Paul D. Smith" <address@hidden> wrote ...
>
> %% "Markus Mauhart" <address@hidden> writes:
>
>   mm> 1) IMHO __FILE__ should be recursively expanded (like MAKEFILE_LIST).
>
> Why?

Cause I had a wrong understanding of makfile processing and simply/recursively
expanded variables, and therefore a wrong test indicating that MAKEFILE_LIST
was recursively expanded too.
So you were right, := does what I really want.

>   mm> 2) take a couple of makefiles, connected via include, more than
>   mm> one of them using __FILE__ with same semantic.
>
> Yes, that's a bad idea... you don't want to do that.

But with "__FILE__ := ..." it makes sense, ok ?

>   mm> Btw, just found AFAICS undocumented behaviour of make:
>
>   mm> //------------------
>   mm> __FILE__ = $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST))
>   mm> __FILE_DIR__ = $(dir $(__FILE__))
>
> You'd better use := here, or it won't work.

right


>   mm> override MAKEFLAGS += -I $(__FILE_DIR__)
>
> Correct.  Changing MAKEFLAGS doesn't impact the behavior of the
> _CURRENT_ version of make, except for some special cases.

Actually 1st I did a simple test like "MAKEFLAGS += A=a" (maybe even
"MAKEFLAGS += VPATH=..."), and for this simple test it had the same effect
on the current makefile as "A=a" allone had.


>  -I cannot be
> a case like that, because the way it works is the MAKEFLAGS variable is
> evaluated before any makefiles are parsed, then the makefiles are
> parsed, then MAKEFLAGS is evaluated (partially, anyway) again.
>
> Changing -I has no impact on the current run because by the time it's
> parsed a second time all the makefiles have already been read in.

understood


>   mm> W.r.t. MAKEFLAGS the docu says:
>   mm> (1) "The options `-C', `-f', `-o', and `-W' are not put into MAKEFLAGS;"
>   mm> (2) "these options are not passed down."
>
> This is talking about invoking make _recursively_; what flags are passed
> to a sub-make.  It's not talking about the current make.

But the recursive invocation is triggered by code I have to write
and understand in the CURRENT makefile; I HAVE to know whether the
current makefile's -I are passed down to the sub-make, whether this
happens via MAKEFLAGS (and therefore I can change pathes), or using
some undocumented magic, or not at all. According to the current docu
-I's are passed via MAKEFLAGS, which turned out to be wrong in my
experiment; probably they arent passed down at all.


>   mm> Yes, I thought of built-in variables that have been added
>   mm> sometimes (dont know exactly when): CURDIR, MAKEFILE_LIST,
>   mm> [...]
>
> Not really, because any value that the makefile sets those values to
> takes precedence over the value that make sets (that's definitely true
> for CURDIR; can't remember about MAKEFILE_LIST).

ok

>   mm> So also your $(TOPDIR)/mk/ contains a file local.mk ?
>
> No.

;-)

> But a solution which doesn't break this usage could not be the same
> as the GNU C preprocessor's method, then, because that doesn't look in
> the working directory at all (unless you give -I.)

Right. Better keep it simple and only add a lookup in the current
makefile's directory (in theory, in my locally patched copy of make).


> Also, I've seen build systems where there are "override" makefiles: if
> the makefile doesn't exist locally with "override" values then a
> "generic" one of the same name in the global area is included (using
> -I).  You could even have many levels of this.
>
> The only backward-compatible way to do this would be to have the
> directory the included makefile was found in searched _last_, after the
> current working directory _and_ all the -I directories were searched.
> Presumably then make would fail anyway because the makefile could not be
> found.
>
> Of course, there is always the added complexity that make could _create_
> the makefile if it didn't exist, rather than finding the "wrong" one.

Same analysis, same conclusion. And this "backward-compatible" algorithm doesnt
cost really more than the current one, and even could display a warning
when it finds a hit via 'old' search (including "_create_ the makefile")
and another one in __FILE_DIR__.
(why warnings ? I'd be interested how often this happens; wouldnt some
of them indicate errors ?).


>   mm> But you have to agree that this required(!) precondition of making
>   mm> make's CURDIR equal to its current source dir
>
> It's in no way "required".  Just add the source dir to the make command
> line with -I.

ok.

>   mm> I just found that make-3.80 doesnt accept 'include "filename"'; so
>   mm> am I right that a syntax-extension for such quoted filenames could
>   mm> implement the search-algorithm I want (or better: exactly like
>   mm> CPP) without breaking existing makefiles (except for bizar
>   mm> filenames like "has_quotes") ?
>
> Possibly.  I'm not in love with that syntax though, and I'm not really
> convinced that this is a real problem with no reasonable existing
> solution.  Certainly I've not had anyone else ask about this before.

(lets remove "(or better: exactly like CPP)")
I'm really surprised that the rest of the world doesnt need include file
lookup in the same directory.
Allthough in C[++] the file search algorithm for inclusion is implementation
defined, can you imagine any implementation not supporting lookup in the
current file's directory ? Or many programs that dont use this ?
Maybe it is cause 'include' isnt much used among most makefile writers ?


>   mm> Or could one use VPATH or vpath ? Just tried it, no chance:
>
> Makefiles are not searched for on VPATH.  They are only searched for as
> described in the manual (the current directory, then the list of
> directories specified with -I).

The copy of the manual in my head said the following:
If an include file is not found, then make will try to remake it, so it
is a target file; when a target file is mentioned as an explicit
prerequisite, then VPATH applies.
Probably a bit wrong ;-)


Regards,
Markus.