View Issue Details

IDProjectCategoryView StatusLast Update
00003381003.1(2008)/Issue 7Shell and Utilitiespublic2010-12-02 16:38
Reporteryaneurabeya Assigned Toajosey  
PrioritynormalSeverityObjectionTypeEnhancement Request
Status ClosedResolutionRejected 
NameGarrett Cooper
OrganizationCisco Systems, Inc.
User Reference
Sectionmake
Page NumberUnknown
Line NumberUnknown
Interp Status---
Final Accepted Text
Summary0000338: Standardization on useful make macros
DescriptionThere are a handful of variables which are used in BSD and GNU make that aren't currently listed in the POSIX spec:

[\.]*CURDIR - the current directory from which the *make application was originally executed [after chdir'ing to the directory specified by -C, if one was specified]. sunmake doesn't appear to have an analog for this.
CXX - the user specified C++ compiler.
CXXFLAGS - the user specified flags that will be passed to the C++ compiler.
MAKEFLAGS - flags (after processing) that are passed to make.

One other thing that isn't mentioned that is typically used in conjunction with .a archives is ranlib. Typical workflows I've run into in the past when producing a .a archive, is to compile objects, archive with $(AR) -rc, then run ranlib on the archive to generate an index with which one could when statically compiling the library into certain architectures, like MIPS.

Unfortunately ranlib isn't listed as a POSIX tool, so I don't think it would be appropriate to place in the POSIX make spec [yet?]. However, it might be worthwhile to look at in a separate Aardvark defect.

CPP/CPPFLAGS weren't noted because they're only really used in the GNU make workflow; thus they might not be incredibly useful for other make implementations.
Desired ActionTo consider standardizing CURDIR/CXX/CXXFLAGS/MAKEFLAGS due to their value in GNU and pmake, as well as their potential utility in sunmake and other make implementations.
TagsNo tags attached.

Activities

eblake

2010-10-19 12:09

manager   bugnote:0000585

CXX and CXXFLAGS don't make sense unless the standard requires C++ support in addition to c99.

CURDIR probably doesn't make sense unless the standard also requires -C command line support.

MAKEFLAGS is already standardized, at line 95576.

And I think that CPP/CPPFLAGS for preprocessor activities would make sense.

yaneurabeya

2010-10-19 19:57

reporter   bugnote:0000587

1. Not sure why CXX/CXXFLAGS wouldn't make sense if C++ / c99 isn't supported in the standard, but ok...
2. There is some merit to CURDIR, as shown below (even without -C support):

$ cat test_curdir.gmake
all: 1 2 3 4 5 6

1:
    cd /tmp && echo $(CURDIR)

2:
    echo $(CURDIR)

3:
    cd /tmp && pwd

4:
    pwd

5:
    cd /tmp && echo $$PWD

6:
    echo $$PWD
$ gmake -f test_curdir.gmake
cd /tmp && echo /usr/home/garrcoop
/usr/home/garrcoop
echo /usr/home/garrcoop
/usr/home/garrcoop
cd /tmp && pwd
/tmp
pwd
/usr/home/garrcoop
cd /tmp && echo $PWD
/tmp
echo $PWD
/usr/home/garrcoop

$ cat test_curdir.pmake
all: 1 2 3 4 5 6

1:
    cd /tmp && echo $(.CURDIR)

2:
    echo $(.CURDIR)

3:
    cd /tmp && pwd

4:
    pwd

5:
    cd /tmp && echo $$PWD

6:
    echo $$PWD
$ make -f test_curdir.pmake
cd /tmp && echo /usr/home/garrcoop
/usr/home/garrcoop
echo /usr/home/garrcoop
/usr/home/garrcoop
cd /tmp && pwd
/tmp
pwd
/usr/home/garrcoop
cd /tmp && echo $PWD
/tmp
echo $PWD
/usr/home/garrcoop

Please note that the value was preexpanded and constant, regardless of the state of the submakes... thus, if it points to an absolute path (which is the case with both gmake and pmake), I can find my way back to the original directory from whence I came. Otherwise I'd have to do something like the following shell snippet to achieve the same level of functionality:

OLDPWD=$$PWD; cd /tmp/ && echo $$OLDPWD; \
# ...

With all of the line continuations and deferring shell variable expansions, as well as having to keep track of another ad hoc, nonstandard shell variable, things would turn into a mess.

3. Good catch on the MAKEFLAGS part; didn't see that before.

4. As stated before, CPP/CPPFLAGS doesn't really have as much relevance in systems other outside of GNU make from what I've seen, because some make programs completely skip the middleman with explicit program rules and don't preprocess sourcecode.

Konrad_Schwarz

2010-10-20 08:56

reporter   bugnote:0000588

The effect of CPPFLAGS in GNU make is easily obtained by setting
CC = c99 $(CPPFLAGS)
resp.
export CC='c99 $(CPPFLAGS)'
in POSIX make resp. the shell.

POSIX make should limit itself to a minimal macro structure; the split
afforded by CC (fixed flags) vs. CFLAGS (override-able flags) is a wide
enough foundation for all uses.

yaneurabeya

2010-10-24 20:49

reporter   bugnote:0000589

"POSIX make should limit itself to a minimal macro structure; the split
afforded by CC (fixed flags) vs. CFLAGS (override-able flags) is a wide
enough foundation for all uses."

Agreed. Making a slim and trim standard is overall the better way to go about things, instead of adding useless functionality.

msbrown

2010-12-02 16:38

manager   bugnote:0000628

The Working Group discussed and considered this proposal, but ultimately felt that there was no consensus for standardization.

Implementations are free to add these functions as extensions, if desired.

Issue History

Date Modified Username Field Change
2010-10-19 11:43 yaneurabeya New Issue
2010-10-19 11:43 yaneurabeya Status New => Under Review
2010-10-19 11:43 yaneurabeya Assigned To => ajosey
2010-10-19 11:43 yaneurabeya Name => Garrett Cooper
2010-10-19 11:43 yaneurabeya Organization => Cisco Systems, Inc.
2010-10-19 11:43 yaneurabeya Section => make
2010-10-19 11:43 yaneurabeya Page Number => Unknown
2010-10-19 11:43 yaneurabeya Line Number => Unknown
2010-10-19 12:09 eblake Note Added: 0000585
2010-10-19 19:57 yaneurabeya Note Added: 0000587
2010-10-20 08:56 Konrad_Schwarz Note Added: 0000588
2010-10-24 20:49 yaneurabeya Note Added: 0000589
2010-12-02 16:38 msbrown Interp Status => ---
2010-12-02 16:38 msbrown Note Added: 0000628
2010-12-02 16:38 msbrown Status Under Review => Closed
2010-12-02 16:38 msbrown Resolution Open => Rejected