Follow-up Comment #3, bug #35485 (project make): I'm not sure how much more specific I can be than saying that "it's just shorthand for $(abspath $(dir $(lastword $(MAKEFILE_LIST))))" but let me try to elaborate.
First, the variability of .MFDIR would be precisely the same as that of MAKEFILE_LIST so it would be no less useful than that. It's true that someone designing a non-recursive build model which relies on including a tree of sub-makefiles would need to pay careful attention to inclusion sequence but again that's the same as with MAKEFILE_LIST for obvious reasons. I believe this limitation is made clear in the original doc patch but there would be no harm in repeating the same warning that comes with MAKEFILE_LIST. So, though I disagree with the statement "this can't possibly be what you want", I agree it could be even more useful if .MFDIR lived on a stack such that it always resolved to the name of the file within which it was evaluated. But as you (Paul) said recently in a different context "in make everything is a time-space tradeoff", so here I was going for the simplest, least invasive solution. If you prefer the stack-based approach I could look into it. Bottom line, MAKEFILE_LIST is quite important for figuring out the "current makefile" in flat/included build models but using it is somewhat obfuscated, and I'm trying to find a way to make it more user friendly. _______________________________________________________ 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