bugmake - Bugs: bug #35485, New $(.MFDIR) built-in variable

 
 

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

Submitter:  David Boyce <boyski>
Submitted:  Wed 08 Feb 2012 06:30:41 PM UTC
   
 
Severity:  3 - Normal Item Group:  Enhancement
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  4.0 Operating System:  Any
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 04 Mar 2012 10:51:46 PM UTC, comment #5: 


> 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.

David Boyce <boyski>
Sat 03 Mar 2012 07:08:15 PM UTC, comment #4: 

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 :-).

Paul D. Smith <psmith>
Group administrator
Mon 27 Feb 2012 02:45:26 PM UTC, comment #3: 

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.

David Boyce <boyski>
Sun 26 Feb 2012 11:28:33 PM UTC, comment #2: 

I don't think this implementation is appropriate.  The value of "MFDIR" will change wildly over time if makefiles are included which can't possibly be what you want.  For example:


.MFDIR = $(abspath $(dir $(lastword $(MAKEFILE_LIST))))
$(info MFDIR = $(.MFDIR))
include foo/bar.mk
$(info MFDIR = $(.MFDIR))
all:;:


will show:

MFDIR = /tmp
MFDIR = /tmp/foo
:


which doesn't seem like what you'd want.  In order to properly implement this, it would need to be handled as a special variable that would be reset properly as make started and stopped processing included makefiles.

Or maybe I'm misunderstanding what you're looking for... perhaps a more specific definition would help.

Paul D. Smith <psmith>
Group administrator
Thu 09 Feb 2012 06:25:01 PM UTC, comment #1: 

T Murphy says:

"I think that getting the directory of the current makefile is useful although I am sure my team have had trouble with  $(abspath) and the way it works in some situations on windows (unfortunately our stuff has to work on both)  - it was something to do with which drive letter got stuck on to a relative path (e.g. off the CWD)  to make it absolute and this possibly not always being the drive letter you wanted.  This is unsubstantiated since my emails about that are stuck in some old Lotus notes database."

To which I say:

A. There will be such corner cases. I have a similar one with Cygwin where we must use cygpath -a -m instead of $(abspath) to translate Unix pathnames into Windows style. But with that said, it's no worse having a shorthand. If abspath is broken on Windows you need to hack around it either way, or fix it in make.

B. It might be better to use realpath instead of abspath. The differences I know of are that the path must exist and symlinks are resolved. In this case the directory is already known to exist and resolving symlinks might be a feature.

C. As noted, it's possible to implement this directly in C code instead which might help work around issues with abspath.

D. Of course if abspath itself is really broken WRT drive letters then that should be fixed, but that's outside scope here.

David Boyce <boyski>
Wed 08 Feb 2012 06:30:41 PM UTC, original submission:  

The attached one-line (plus docs) patch adds a .MFDIR variable which evaluates to the directory of the containing makefile, more or less. It's actually just shorthand:

diff -u -r1.60 default.c
--- default.c   16 Jan 2012 02:29:22 -0000      1.60
+++ default.c   8 Feb 2012 17:45:49 -0000
@@ -527,6 +527,7 @@
 #endif

 #endif /* !VMS */
+    ".MFDIR", "$(abspath $(dir $(lastword $(MAKEFILE_LIST))))",
     0, 0
   };

Justification: though this adds no new functionality, I think it's important for support of non-recursive build styles. Given a build tree with many directories containing source files and makefiles, in a recursive model the tendency is to cd into each directory and invoke make locally, and thus the important relative directory is the cwd aka $(CURDIR). But in a flat build model those sub-makefiles tend to be included into a single make process and CURDIR doesn't change. In this case the important relationship is with the directory containing the controlling sub-makefile. Currently the playing field is tilted towards cwd-centric builds by the support for CURDIR. Having .MFDIR would even that out by making it easier to think in terms of a makefile-relative directory. Expecting naive (or even expert) developers to qualify paths with "$(abspath $(dir $(lastword $(MAKEFILE_LIST))))" is a nonstarter.

This could be made more verbose as MAKEFILE_DIR or less as MWD. The leading "." is just my guess as to what would be most compatible.

Also, it's arguable whether this is better handled as a regular predefined variable, subject to removal with -R, or a hard-wired variable analogous to CURDIR.

David Boyce <boyski>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #25027:  mfdir.diff added by boyski (2KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by boyski (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-02-08 boyski Attached File- Added mfdir.diff, #25027

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code