View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000338 | 1003.1(2008)/Issue 7 | Shell and Utilities | public | 2010-10-19 11:43 | 2010-12-02 16:38 |
Reporter | yaneurabeya | Assigned To | ajosey | ||
Priority | normal | Severity | Objection | Type | Enhancement Request |
Status | Closed | Resolution | Rejected | ||
Name | Garrett Cooper | ||||
Organization | Cisco Systems, Inc. | ||||
User Reference | |||||
Section | make | ||||
Page Number | Unknown | ||||
Line Number | Unknown | ||||
Interp Status | --- | ||||
Final Accepted Text | |||||
Summary | 0000338: Standardization on useful make macros | ||||
Description | There 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 Action | To 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. | ||||
Tags | No tags attached. |
|
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. |
|
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. |
|
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. |
|
"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. |
|
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. |
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 |