[bug #35485] New $(.MFDIR) built-in variable

[David Boyce]

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/