Follow-up Comment #5, bug #35485 (project make): > I don't think the "stack-based approach" is actually more runtime or space intensive ...
I don't think so either. I just meant it would be a more intrusive change in terms of diff size than the one-liner proposed here. But if you're that it's not, this is good news. > 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. I don't think we disagree that much. First, I don't care so much about whether the path is canonicalized, though I do kind of prefer it aesthetically. Second, it's true that a variable which evaluates to the currently parsing makefile would go a significant way toward addressing my concern. In other words I could live with it. That said, I don't think you've addressed the core of my point which is basically pedagogical. I think "the directory of the current makefile" is a fundamental concept, just as important to single-DAG systems as "the current working directory" is to process-recursive build models, and deserves to be treated that way. Yes, "MFDIR" could be derived easily from "the current makefile", but that still leaves it a second class citizen. As noted, though, I could certainly live with the compromise. I can live with the current state of things too, for that matter, I just think it's a bit sub-optimal. _______________________________________________________ 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