Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001420 [1003.1(2004)/Issue 6] Shell and Utilities Editorial Clarification Requested 2020-11-07 20:27 2020-11-08 23:43
Reporter psmith View Status public  
Assigned To ajosey
Priority normal Resolution Open  
Status Under Review  
Name Paul Smith
Organization GNU Project
User Reference
Section make
Page Number
Line Number
Interp Status ---
Final Accepted Text
Summary 0001420: Clarification: where are internal macros available?
Description In the section "Internal Macros" we see:

> The make utility shall maintain five internal macros that can be used in target and inference rules.

It is not clear from this text what is meant by "can be used in ... rules". In GNU make for example, internal macros (called "automatic variables" in the GNU make manual) are available only within the commands of a rule but not available within the prerequisites of a rule.

Does the statement "can be used in" mean to suggest that these macros can be used in the prerequisites list of a given rule as well?

If so, we must clarify what it means when a non-$@ variable is used in the prerequisites list.
Desired Action Change the text:

The make utility shall maintain five internal macros that can be used in target and inference rules.


The make utility shall maintain five internal macros that can be used in the commands of target and inference rules.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
joerg (reporter)
2020-11-07 22:01

Your seem to miss that the macros $< and $* are undefined in case of explicit rules.

smake does not expand $< or $* for explicit rules.

SunPro Make and gmake both expand these macros, but use completely incompatible rules to expand these macros in case of explicit rules. These rules result in the same expansion for some constraints and give different results for other constraints. Your text thus is inacceptable for standardization.

BTW: The background for this question was a question from a bug-tracking system that has been caused by an incompatibility in the BSD make program and was related to the use of $@ in the dependency list of an explicit target rule.

Make macros seen in the dependency list of a target rule are expanded by the parser already and at that time, $@ is undefined.
psmith (developer)
2020-11-08 13:42

I am aware of the difference in $< and $* in explicit rules. My suggested change is not related to that, and doesn't make this behavior any more or less defined WRT POSIX than it is now, so that is not relevant as to whether the suggested change is acceptable. If you wanted to make the handing of these internal macros inside of explicit rules more clear than it currently is, please file a separate issue and we can discuss there.

> Make macros seen in the dependency list of a target rule are expanded by the parser already and at that time, $@ is undefined.

You (and I) may _believe_ that, but the text of the standard doesn't _say_ that. Hence my request for clarification.

If you think the standard DOES say that already please quote the text that says so.

My suggested change ONLY makes clear that internal macros are not defined except for inside commands. It is not intended to address any other issue than that.
joerg (reporter)
2020-11-08 16:17

In order to avoid missinterpretations with the dynamic macros, I like to make an alternate proposal that is aligned with the behavior of the UNIX make utility.

Change the following sentence on page 2898 line 97447 from:

      The make utility shall maintain five internal macros that can be used in
      target and inference rules.


      The make utility shall maintain five internal macros that shall be expanded
      in the command sections of rules. Not all of these internal macros are
      expanded with all types of rules, see the detailed description below and
      the rationale section for the the System V dynamic dependency feature.
psmith (developer)
2020-11-08 16:52

I don't see the point in making this statement, since each explanation of the individual internal macros explains which types of rules it is required for and which it is not required for. For example, the $< macro description already says "The meaning of the $< macro shall be otherwise unspecified." (other than implicit rules and .DEFAULT), etc.

I don't think it's needed to refer to the rationale section from within the standard like this; the existing text is very clear on this point without it.

My concern here is specifically whether internal macros need to be assigned before the prerequisites are expanded, or not. The standard is not clear (enough) on this point, in my opinion.

Perhaps a change like this would be sufficient:

  The make utility shall maintain five internal macros that will be assigned
  while the commands of target and inference rules are evaluated, as described

Just to clearly point people to the individual macro discussions to follow.
joerg (reporter)
2020-11-08 21:30

The proposed text from Note: 0005106 does not really contain a new
statement, since that information is already available if you
combine existing statements from different locations in the
standard text for the make utility.

On the other side, your proposal still does not seem to directly answer the
related question from your customer in your bug data base.

The dynamic macros are specified as returning values that are only
available while a target rule or an inference rule is evaluated.

On the other side, the standard already mentions that while reading
target rules by the parser, contained macro references in every
target rule need to be expanded immediately. At that time, a value
for $@ however is not available, so the rule

tgt: $@.c

needs to be expanded into

tgt: .c

while specifying

tgt: $$@.c

is required to expand to:

tgt: $@.c

at parse time and that may later be expanded as dynamic dependency
at the time the rule is evaluated. Well, in case the make program
implements support for the dynamic dependency feature that is not
required by POSIX.
psmith (developer)
2020-11-08 23:43

> At that time, a value for $@ however is not available,

You are _assuming_ that, because that's how implementations of make (that attempt to be POSIX compliant) work today: the standard does not _say_ that they are not available. That's the problem.

If you can find text in the standard that says that $@ is not set before prerequisites are expanded, please quote that text.

There's nothing in the standard that I can find that says that make doesn't have to work like this:

* Read in the rule definition line
* Expand the target
* Assign the internal macro $@ to the name of the target
* Expand the prerequisites

And in fact, the current wording of the standard is ambiguous enough that it could be argued that it IS required: the standard says that internal variables "can be used in target and inference rules". The prerequisites are definitely part of target and inference rules.

All I want in this issue is to clear this one thing up. I'm not trying to add new requirements, discuss $$@, etc. Merely clarifying that internal macros are only required to be available in the commands, not "in target and inference rules" generally, is sufficient and nothing else needs to be added.

- Issue History
Date Modified Username Field Change
2020-11-07 20:27 psmith New Issue
2020-11-07 20:27 psmith Status New => Under Review
2020-11-07 20:27 psmith Assigned To => ajosey
2020-11-07 20:27 psmith Name => Paul Smith
2020-11-07 20:27 psmith Organization => GNU Project
2020-11-07 20:27 psmith Section => make
2020-11-07 22:01 joerg Note Added: 0005103
2020-11-08 13:42 psmith Note Added: 0005104
2020-11-08 16:17 joerg Note Added: 0005105
2020-11-08 16:52 psmith Note Added: 0005106
2020-11-08 21:30 joerg Note Added: 0005107
2020-11-08 23:43 psmith Note Added: 0005109

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker