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

[Paul D. Smith]

%% "Markus Mauhart" <address@hidden> writes:

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

Why?

  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.

  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.

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

  mm> #adjust MAKEFLAGS --> this has not the expected effect;
  mm> #allthough MAKEFLAGS gets changed, the change is not used
  mm> #when searching for include files.
  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.  -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.

  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.

  >> Were you thinking of something in particular?

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

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).

  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.)

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.

  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.

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

If you want to use VPATH, that's one way to go.

  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.

  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).

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist