Re: how vpath should behave

[Paul Smith]

I'm adding help-make back; hope you don't mind.  I prefer to keep all
discussion of make on the lists.

On Wed, 2021-05-19 at 16:45 -0800, Britton Kerin wrote:
> > They are there to find _SOURCES_ (that is, files that make does not
> > build itself but that already exist before make starts).
> 
> Ok but it seems somewhat weird and asymmetric to restrict it in this
> way.  Elsewhere make specializes in letting you incrementally turn
> sources into targets and tack things onto either end of the pipeline
> however you want.  It seems that the surprising behaviors of vpath
> comes from this asymmetry.

I don't disagree, necessarily, but it's a result of how make works,
where it starts from the FINAL GOAL and works BACKWARD.  This means it
knows what target it wants to build: make doesn't work FORWARD where it
finds some source file and runs a command then sees what target got
built.  My blog post tries to explain this.  There is, of course, no
way to change this absolutely foundational design choice.

Make always assumes that your recipe builds the target that it asked
you to build (the value of $@), so it needs to compute the value of $@
_BEFORE_ the recipe runs.  Something like vpath, which says "go and
find the file", cannot do that for built targets obviously.

I guess one possibility would be to create an entirely new "thing", say
"TPATH" (for target path), which would be searched AFTER a recipe is
run.  This would mean that the $@ value would always be exactly what
appears in the makefile, and then after the recipe runs we check to see
if that exists.  If it does, fine; if not then we search directories in
TPATH for the target to see if it exists; if so then we change all
prerequisites that mention this target to use this new path.

I think there are a lot of opportunities for confusion and weird side-
effects here but I'd have to think about it more deeply than this off-
the-cuff idea.

> Well it is interesting but to be honest
> 
> http://make.mad-scientist.net/papers/multi-architecture-builds/#advanced
> 
> seems almost as tortured as the stuff I've come up with :)

Yes, I don't actually recommend that method much anymore.  I usually
just tell people to use the model that make was designed for: if you
want to build in a "remote" directory, then cd to that directory and
run make from there.  This has the added advantage that you can have as
many different "remote" directories for the same source directory as
you want: the name of the remote directory isn't hardcoded in the
makefile.