bugmake - Bugs: bug #9062, Need access to pathname of Makefile


bug #9062: Need access to pathname of Makefile

Submitter:  Dave Yost <yost>
Submitted:  Sat 22 May 2004 05:17:44 PM UTC
Votes: 20
Severity:  3 - Normal Item Group:  Enhancement
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  3.80 Operating System:  Any
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Mon 03 Apr 2006 07:27:30 AM UTC, comment #11: 

A reminder: this bug is a request for a variable whose value is the full path of the directory containing the Makefile, regardless of what the current directory is or how it got that way with -C, etc.

There has been much discussion of the current directory, which is not relevant.

Dave Yost <yost>
Mon 03 Apr 2006 05:58:05 AM UTC, comment #10: 

GNU make does not and has never supported a built-in variable $(PWD).

Of course, GNU make does now and has always (just like every other make) imported environment variables exported from the invoking process into GNU make variables, and some shells do set and maintain a $PWD environment variable.

So if your shell is one of those, then you would see a $(PWD) variable in make as well; but this is nothing GNU make is creating.  It's 100% dependent on the feature set of the shell invoking GNU make (never a good idea for a portable make environment!!)

If you use "make -p" so GNU make prints its database, it will tell you exactly where every variable defined came from.

Paul D. Smith <psmith>
Group administrator
Sun 02 Apr 2006 04:30:43 AM UTC, comment #9: 

What is the difference between ${PWD}, which was supported by
GNU make for many years, and ${CURDIR}, which was introduced in
release 3.76.1? If there is no difference, why the new variable
was introduced? It is not just my curiosity :-). We plan to support
GNU make extensions in Sun Studio dmake, and all these small details matter.

Nikolay Molchanov <nikm>
Sun 02 Apr 2006 02:59:19 AM UTC, comment #8: 

Even simpler is to look at the NEWS file; all user-visible changes should be documented there:

Version 3.80

  • A new built-in variable is defined, $(MAKEFILE_LIST). [...]


Version 3.77

  • Make defines a new variable, "CURDIR", to contain the current working

  directory (after the -C option, if any, has been processed).
  Modifying this variable has no effect on the operation of make.

Paul D. Smith <psmith>
Group administrator
Sun 02 Apr 2006 01:37:00 AM UTC, comment #7: 

From the make ChangeLog:

2002-10-03  Paul D. Smith  <psmith@gnu.org>

        Version 3.80 released.

2002-06-06  Paul D. Smith  <psmith@gnu.org>
        * read.c (read_all_makefiles): Create a new built-in variable,

2000-06-23  Paul D. Smith  <psmith@gnu.org>

        * Version 3.79.1 released.

And, from ChangeLog.2:

1998-05-20  Paul D. Smith  <psmith@gnu.org>

  • Version 3.76.90 released.

1998-04-11  Paul D. Smith  <psmith@gnu.org>

  • main.c (main): Set the CURDIR makefile variable.

Fri Sep 19 09:20:49 1997  Paul D. Smith  <psmith@baynetworks.com>

  • Version 3.76.1 released.

Martin Dorey <mdorey>
Sun 02 Apr 2006 01:24:47 AM UTC, comment #6: 

I tried to use ${CURDIR} and ${MAKEFILE_LIST} with a GNU make
on Solaris, but these variables are empty. In what version of
GNU make they appear? I think they work in 1.80, correct?
Here is what I tried:

% uname -a
SunOS volga2 5.9 Generic_112233-07 sun4u sparc SUNW,Ultra-60
% gmake -version
GNU Make version 3.74-96q4, by Richard Stallman and Roland McGrath.
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS

% cat Makefile

        echo "Directory = $d"
        echo "CURDIR=${CURDIR}"
        echo "Makefile = $m"

% gmake
echo "Directory = "
Directory =
echo "CURDIR="
echo "Makefile = "
Makefile =

There is a standard env. variable ${PWD}, which contains the path
to the current directory. It is supported by Solaris make, GNU
make, and some other make utilities.

Nikolay Molchanov <nikm>
Mon 24 May 2004 09:14:59 PM UTC, comment #5: 

I'm not saying it's perfect, but you can do in a more straightforward manner than that:

  this := $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST))
  parentDir := $(if $(findstring /,$(this)),$(patsubst %/,%,$(dir $(this))),.)

And you can make a user function for it (maybe included in a general rules makefile) like this:

  GET_PARENT_1 = $(if $(findstring /,$1),$(patsubst %/,%,$(dir $1)),.)
  GET_PARENT = $(call GET_PARENT_1,$(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST))

Then you can use it like this:

  parentDir := $(call GET_PARENT)

which isn't so bad.  Of course this won't work for the first makefile; for that you can use:

  parentDir := $(call GET_PARENT_1,$(firstword $(MAKEFILE_LIST))

Again, not perfect, but it's there now.

Paul D. Smith <psmith>
Group administrator
Mon 24 May 2004 06:26:37 PM UTC, comment #4: 

Yes, it is possible, but it makes for a barrage of gunk that is all the more unfortunate because it has to be at the top of the Makefile.  Below is what I came up with for an intermediary included Makefile.  The proposed built-in variable would eliminate all of this clutter.

# Find the parent directory of this file.
# Requires make version 3.80 or later.

# Get the pathname of this file
this := $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST))
# Extract the directory part of that path.
ifeq (/,$(findstring /,$(this)))
    # Remove the last slash and everything after it.
    parentDir := $(shell x=$(this) && echo $${x%/*})
    parentDir := .


include $(parentDir)/../../../../Makefile-include

Dave Yost <yost>
Mon 24 May 2004 05:24:42 PM UTC, comment #3: 

Well, the current working directory when make starts is available in the CURDIR variable.  And the makefile that is currently being managed is available in MAKEFILE_LIST, even if it's the original makefile.

It's not trivial to manage this but it is possible, I think.  It's not any harder, I don't think, than doing it in the shell.  You either invoke a subshell to cd over there and run pwd, or you construct the path by appending the other directory names as you go.

Paul D. Smith <psmith>
Group administrator
Mon 24 May 2004 01:41:08 AM UTC, comment #2: 

I suppose if I do this only from an included file, I'll be OK.  But in the general case, you can't get the current file path from MAKEFILE_LIST.

Dave Yost <yost>
Sun 23 May 2004 08:48:29 PM UTC, comment #1: 

You can find the path used to include the makefile by looking at the last word in the MAKEFILE_LIST variable.

Paul D. Smith <psmith>
Group administrator
Sat 22 May 2004 05:17:44 PM UTC, original submission:  

Consider a Makefile that starts thus:

    root := ../../..
    include ../../../Makefile-master

It would be nice if this included Makefile-master knew where it was, so it could do something like this:

    root := $(MAKEFILE-PARENT-DIR)
    classesDir := $(root)/classes

Having to explicitly set the 'root' variable in the top-level Makefile is a workaround that works, but it would be nice if the workaround could be eliminated.

A shell script can know where it is and what its name is.  The same should be true for Makefiles.  Here's how I do it in sh:

if [[ "$commandDir" = "$commandName" ]] ; then

Dave Yost <yost>


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

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by takota (Voted in favor of this item)

    There are 20 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.


    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-07-09 takota Carbon-Copy- Added takota
    2006-09-27 yost Carbon-Copy- Added yost

    Back to the top

    Powered by Savane 3.13-04b1.
    Corresponding source code