Follow-up Comment #4, bug #35485 (project make):
OK, let me put it another way: I don't think there's much value in creating a
new built-in variable which is just shorthand for something so easily defined
by the makefile author. If we add a new variable I'd prefer it solve a real
problem, and provide behavior which is not otherwise easily obtainable.
I don't think the "stack-based approach" is actually more runtime or space
intensive, since make already has to preserve the include stack internally in
order to be able to pop, write error messages containing the makefile name,
etc. I'd be surprised if there's too much more to it than adding a
define_variable() function call in the appropriate place(s) in read.c.
Although, I am not sure what I would like will be what you're looking for,
because what I'd like to see is a variable containing the "currently parsing"
makefile. You are looking for a variable containing the canonical directory
path of the currently parsing makefile. I don't know that I'm so jazzed about
adding a built-in for the latter given that we have support for the former...
just as in my first paragraph above :-).
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?35485>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
