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

[Markus Mauhart]

"Paul D. Smith" <address@hidden> wrote ...
>
>   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.

That's why I said a working non-builtin __FILE__ would be complicated, cause
each file using it needed to contain support code as prefix AND suffix.
E.g. assume a top-level makefile including all other files:

//top-level file:
    var_from_file = var_$1

    define __FILE__and_include_guard_prefix
    tmp := $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST))
    #ifndef $$(call var_from_file,$$(tmp)) ... doesnt compile
    $$(call var_from_file,$$(tmp)) := $$(__FILE__)
    __FILE__ := $$(tmp)
    endef

    define __FILE__and_include_guard_suffix
    __FILE__ := $($(call var_from_file,$(__FILE__)))
    #endif
    endef

//any other file:
    $(eval $(__FILE__and_include_guard_prefix))
    .
    .
    .
    $(eval $(__FILE__and_include_guard_suffix))


Any clue why the ifndef/endif-stuff doesnt compile ("*** missing `endif'") ?


>   >> 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 thought that when wanting strict compatibility one would look inside
the current file's directory only after the WHOLE current procedure came
to an end (positive or negative, including 'try to rebuild').

But what I dont like with this way is that a file found only by this 'new'
procedure would have to be handled like a file that has been created
-> restart make :-( ... IMHO this result then is not worth the effort.


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

I will keep this option in my mind.


>   >> Makefiles are not searched for on VPATH.  They are only searched
> [...]
> 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.

And even if it worked, wouldnt this method too force a restart of make ?


For now I think that the __FILE__-simulation from above plus
"include $(dir $(__FILE__))any.mk" is good enough; added support of
builtin __FILE__ or of [include "asd.mk" -> start looking in current
file's directory] doesnt sound bad too ;-)


Regards,
Markus.