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
0001471 [Issue 8 drafts] Shell and Utilities Editorial Enhancement Request 2021-05-16 12:15 2021-05-22 19:02
Reporter joerg View Status public  
Assigned To
Priority normal Resolution Open  
Status New   Product Version
Name Jörg Schilling
Organization
User Reference
Section make
Page Number 2888-
Line Number 97001-
Final Accepted Text
Summary 0001471: Add an orthogonal interface for immediate macro expansion definitions to make
Description GNU make introduced a ::= macro assignment where the value is first expanded and then assigned.

This has pitfalls, as it at the same time introduces a non-predictive behavior of the (since 35 years existing) += operator.

In order to allow predictive behavior, two new operators should be introduced:

macro:::=value

and

macro +:=value

The first (:::=) causes an assignment with immediate expansion but is creating the same macro type as reated with macro=value. Macros created with macro:::=value are delayed appended with macro +=value as usual.

The second (+:=) causes an append assignment with immediate expansion, regardless of whether the macro has been created by macro=value, macro::=value or macro:::=value before.

This feature is implemented by SunPro Make and smake since a while, see the current SunPro Man Page at:

http://schilytools.sourceforge.net/man/man1/make.1s.html [^]

and the current smake man page at:

http://schilytools.sourceforge.net/man/man1/smake.1.html [^]
Desired Action On page 2888 line 97001 change

macro=value
macro::=value

to

macro=value
macro::=value
macro:::=value

After page 2894 line 97263 add:

The following form defines a normal delayed-expansion macro (replacing any previous definition of the macro named by string1):

string1 :::= [string2]

by immediately expanding string2 before assigning the value.

After page 2895 line 97282 add:

The following form (the append form) appends additional text to the value of a macro:

string1 +:= [string2]

When using this append form:

- If the macro named by string1 does not exist, this form shall be equivalent to the immediate-expansion form

  string1 :::= [string2]

- If the macro named by string1 exists, then a <space> or <tab> character followed by the evaluation of string2 shall be appended to the value currently assigned to the macro named by string1.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0005356)
shware_systems (reporter)
2021-05-16 14:35

Personally, I'd rather see ":+=" than ":::=", as keeping operators under 4 chars long, harder to typo, and more mnemonic of being related to "+:=" in intent. While this would be a breaking change for the relatively few SunPro make files that use the 4 char form now, it'll be clearer for users of other makes that add this.
(0005357)
psmith (developer)
2021-05-16 17:18

I don't see a need for these new operators to be standardized. GNU make has implemented the immediate/delayed assignment operators more or less as they are described in the standard today for over 25 years and there haven't been any requests that I recall to add more capabilities such as the ones described here.
(0005358)
shware_systems (reporter)
2021-05-16 19:02

On the phone calls where this was originally brought up cases were brought up where assignment expressions executed later could have different results depending on the initial assignment. This could break boilerplate makefiles user provided makefiles were expected to reference, resulting in a much larger documentation requirement for those files to let end users know those variables were sensitive. The addition of these allows such boilerplate to be insensitive to which type of original assignment happened, and this was considered of enough future usability Jeorg was asked to put this ER together.
(0005359)
kre (reporter)
2021-05-16 19:12

Something existing only in SunPro make (and smake, which is more or less
a derivative) is clearly not the standard.

For any of this to be adopted, it would need to have been implemented by
at least a couple of other relatively major make implementations.

It doesn't matter in the slightest what problems it might solve, this group
is not a legislature, and should never be attempting to force implementations
into something that their users are not demanding.
(0005360)
shware_systems (reporter)
2021-05-16 19:49

As something addressing possible portability issues I believe additions like this are in scope for the standard. If you can point to where they are explicitly excluded from consideration that I've missed somehow I'll be hapy to look at that. The criteria I'm aware of for such additions is that it has been implemented at least once as proof of concept, not that all known implementations have to have adopted it. These now have 2 implementations.
(0005361)
joerg (reporter)
2021-05-16 21:26
edited on: 2021-05-16 21:27

Re: Note: 0005359

smake is much older than SunPro Make and I am very sure that
SunPro Make is not based on smake.

So we have two completely independent implementations that implement
the proposal with different implementation problems. Also note that
Mark already mentioned that a single implementation is sufficient to prevent
this proposal from being a POSIX invention. Finally the GNU make ::=
addition was implemented by one make variant only and is (in constrast
to this proposal) really hard to implement in other makes.

Adding this proposal to a cleanly written make takes approx. 2-4 hours,
so be sure whether you like to spend more time in arguing than it
would take to implement.

BTW: The number of halfway POSIX compliant make implementations is
very modest.

(0005363)
psmith (developer)
2021-05-22 19:02

Regardless of code provenance it's hard to consider SunPro make and smake "independent implementations" when one person is maintaining and updating both of them. These new operators have been available for about two months now: I don't see how it's possible that any users, other than the maintainers perhaps, have had a chance to use even the original ::= much less come to the conclusion that there's a problem and decide they need new alternatives.

I won't argue that "::=" was implemented by one make variant. However, the capability was available and proven in GNU make for decades, not months, and was heavily used in almost all GNU make-specific makefiles; additionally the concept of an immediately expanded variable is simple and powerful and something that many users want; that may be why it was adopted.

In contrast, these new assignment operators seem (to me) to be esoteric and rarely needed. As I mentioned above, I don't recall any requests for anything like these new operators from the GNU make userbase in the last 25+ years.

Regarding amount of work to implement these new operators: it might be true that in terms of the bare code it's not excessively difficult (I'm not sure but I have no reason to disagree offhand). However just because it's not a lot of work doesn't mean it belongs in the standard.

Also consider that in addition to the code changes there is more work that needs to be done:

There will have to be a suite of regression tests added to GNU make verify these new operators behave with all the existing operators and in all contexts.

These new operators have to be documented. GNU make provides a full user's manual, in addition to the man page, which is expected to include thorough details of their behavior, clear explanations of how they differ from the other operators, as well as practical examples of when and how these operators might be used. Simply adding the text above won't be sufficient.

Finally, GNU make has other facilities beyond POSIX, and these new operators will have to be tested with them as well; target- and pattern-specific variable assignments at least certainly need to be considered.


Fundamentally, I'm not convinced that there's any need for these operators to appear in the standard.

- Issue History
Date Modified Username Field Change
2021-05-16 12:15 joerg New Issue
2021-05-16 12:15 joerg Name => Jörg Schilling
2021-05-16 12:15 joerg Section => make
2021-05-16 12:15 joerg Page Number => 2888-
2021-05-16 12:15 joerg Line Number => 97001-
2021-05-16 14:35 shware_systems Note Added: 0005356
2021-05-16 17:18 psmith Note Added: 0005357
2021-05-16 19:02 shware_systems Note Added: 0005358
2021-05-16 19:12 kre Note Added: 0005359
2021-05-16 19:49 shware_systems Note Added: 0005360
2021-05-16 21:26 joerg Note Added: 0005361
2021-05-16 21:27 joerg Note Edited: 0005361
2021-05-22 19:02 psmith Note Added: 0005363


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