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

[Paul D. Smith]

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

  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> But with "__FILE__ := ..." it makes sense, ok ?

No variable in make is "file scoped", all variables have either global
scope or target scope.  If you set __FILE__ in each of your makefiles
then as soon as you include the second one, that setting of __FILE__
will override the first setting.

  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.

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

Yes, this will work as if you had put "A=a" as the last thing in the
last makefile that make read.

  >> This is talking about invoking make _recursively_; what flags are
  >> passed to a sub-make.  It's not talking about the current make.

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

I'll have to test this; I thought they were passed down but I admit I'm
not sure.

  >> 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> Same analysis, same conclusion.

I don't think it behaves the same: in the current behavior it would not
find the makefile in the other directory, so it would rebuild it locally
(given a rule that knew how to do this).  In your environment it would
find it by virtue of being included from another file in that directory,
so it would use that one instead of the local one.

I admit this is a heck of a lot of "if this then that".

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

No, it's used all the time.  But most setups work by having one local
makefile that includes one or more "global" makefiles.  The path to the
global makefiles has to be provided to make with -I, because that's the
easiest way to find it.  And all the other included makefiles are in
that same global directory, so they're found through that same -I
anyway.

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

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

Yes, this argument has been made before and I even somewhat agree with
it.  But, I've never done the due diligence to decide whether it would
work properly.

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