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-07-29 18:07
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.
(0005393)
geoffclare (manager)
2021-07-08 16:43

During the July 8, 2021 teleconference Joerg claimed that the proposed behaviour for :::= is the same as the behaviour of := in BSD make. It is surprising that this has not been mentioned before in this bug, so can someone with access to BSD make confirm this?

I.e. does this:

printf 'A = 1\nB := $$(A)\nall:\n\techo '\''$(B)'\''\n' | make -f -

output 1, or does it output $(A) like GNU make?
(0005394)
hvd (reporter)
2021-07-08 16:57

> I.e. does this:

> printf 'A = 1\nB := $$(A)\nall:\n\techo '\''$(B)'\''\n' | make -f -

> output 1, or does it output $(A) like GNU make?

With bmake (http://crufty.net/help/sjg/bmake.html, [^] a portable version of NetBSD make), this outputs 1.
(0005395)
steffen (reporter)
2021-07-08 19:30

#?0|kent:toolbox.git$ printf 'A = 1\nB := $$(A)\nall:\n\techo '\''$(B)'\''\n' | make -f -
echo '$(A)'
$(A)
#?0|kent:toolbox.git$ printf 'A = 1\nB := $$(A)\nall:\n\techo '\''$(B)'\''\n' | smake -f -
smake: WARNING: Nonportable ':=' assignment found for macro 'B' in line 2 col 4 of 'Standard in'
...echo '1'
1
#?0|kent:toolbox.git$ printf 'A = 1\nB := $$(A)\nall:\n\techo '\''$(B)'\''\n' | bmake -f -
echo '1'
1
(0005396)
steffen (reporter)
2021-07-08 19:32

P.S.: bmake is also used on FreeBSD. Output with the newest version under Linux.
(0005397)
kre (reporter)
2021-07-08 20:01

On actual NetBSD, both an oldish NetBSD 8 (from Jan 2018)
and an (almost) current HEAD

jinx$ printf 'A = 1\nB := $$(A)\nall:\n\techo '\''$(B)'\''\n' | make -sf -
$(A)

netbsd# printf 'A = 1\nB := $$(A)\nall:\n\techo '\''$(B)'\''\n' | make -sf -
$(A)

(I added the -s to supress the echo command itself). I am not sure why
Simon's bmake appears to be different, I will ask him. But I suspect
the answer will be the same as the last time I asked something like this
(paraphrasing) "bmake doesn't get updated very often".

When I look on NetBSD 6 vintage systems (circa 2013) ...

munnari$ printf 'A = 1\nB := $$(A)\nall:\n\techo '\''$(B)'\''\n' | make -sf -
1

So this looks to be something that was changed sometime between 2013
and 2018.
(0005398)
steffen (reporter)
2021-07-08 20:21

.. i had not seen hvd's posting at first.
But here, no, this is the very very current bmake that has been imported into FreeBSD about two weeks ago or so. I package it for a Linux distribution.

t$ prt-get info bmake
Name: bmake
Path: /usr/ports/contrib
Version: 20210621
Release: 1
Description: NetBSD make program
URL: http://www.crufty.net/help/sjg/bmake.html [^]
Maintainer: Steffen Nurpmeso, steffen at sdaoden dot eu

P.S.: the portable branch requires two tests to be disabled on Linux. Interesting problem, the standard is explicit and says signals which were not ignored upon program start _only_. Which i deem problematic for SIGINT for example, given that bmake at least supports interrupt handlers etc. Let's see what the future brings. The standard is like this, however.
(0005399)
steffen (reporter)
2021-07-08 20:34

P.S.: to be explicit, the tests have to be disabled only if running in an unshare(1) based container "as in"

  /usr/bin/unshare --ipc --uts --pid --fork make

because that seems to ignore SIGINT++.
(0005400)
kre (reporter)
2021-07-08 21:15

Simon says (just had to start like that!) :

  The answer is "it depends" ;-)

  Tranditionally it would have output 1
  and still does if .MAKE.SAVE_DOLLARS=no

  The behavior was changed a few years ago (to be more
  compatible with GNU make ;-), so now it outputs $(A) by
  default. I added .MAKE.SAVE_DOLLARS so that the traditional behavior
  (which my dirdeps.mk depends on) can be selected.

  In recent bmake it all depends on the value of .MAKE.SAVE_DOLLARS
  there are a couple of *.mk files in bmake that set .MAKE.SAVE_DOLLARS=no

He also said he would take a look at this issue (I sent him its URL) but
perhaps not for a few days.
(0005401)
steffen (reporter)
2021-07-08 22:33

Yes.

$ printf 'A = 1\nB := $$(A)\nall:\n\techo '\''$(B)'\''\n' |
  bmake .MAKE.SAVE_DOLLARS=yes -f -
echo '$(A)'
$(A)
You have new mail in /var/mail/steffen

And it is nicely documented also

    .MAKE.SAVE_DOLLARS
                     value should be a boolean that controls whether ‘$$’ are
                     preserved when doing ‘:=’ assignments. The default is
                     false, for backwards compatibility. Set to true for com‐
                     patability with other makes. If set to false, ‘$$’
                     becomes ‘$’ per normal evaluation rules.

Well i did not know (read the manual!), but i also will not change the defaults for the package i maintain.
(0005402)
steffen (reporter)
2021-07-08 22:33

Thanks, kre.
(0005403)
joerg (reporter)
2021-07-10 12:30

Re: Note: 0005393

Geoff, your test script is unfortunately not sufficient to investigate
and understand the problem caused by the deviating behavior implemented
in GNU make.

This is because there are two deviations in GNU make compared to other
make implementations and your script only tests for one of them. To test
for the other deviation, you could use this script:

  printf 'A = immediate\nB := b\nB += $A\nA = delayed\nall:\n\techo '\''$(B)'\''\n' | $MAKE -s -f -

smake prints:
smake: WARNING: Nonportable ':=' assignment found for macro 'B' in line 2 col 4 of 'Standard in'
b delayed

bmake prints:
b delayed

and gmake prints:
b immediate

As you see, smake and bmake fully agree and the deviating behavior from
gmake never should have made it into the standard. In special: If the
gmake documentation would have clearly pointed to it's deviating
behavior, I would have protested against 0000330 When 0000330 was
discussed in the teleconference. During that teleconference, I was
assuming, gmake was aligned with the behavior of other make
implementations like smake and bmake.

Note that the change in bmake regarding the expansion of := macros
at use time (see your test script) has been introduced after 2015, which
is years after 0000330 was closed with a wrong decision.

Also note that the tool people from netbsd yesterday clearly judged that
the deviating gmake behavior for += tested with the script from this
bugnote is seen as a bug by them.
(0005404)
psmith (developer)
2021-07-10 18:03

I reject the assertion that GNU make's documentation doesn't clearly define the behavior of "+=" in the context of immediately expanded variables. There's an entire section of the manual devoted to this, with examples:

  https://www.gnu.org/software/make/manual/html_node/Appending.html [^]

I also don't agree that this behavior wasn't well-described by the request to add ::= and += to the standard. I can't speak to what was or wasn't discussed in the teleconference but the change text is clear:

> The following form (the "append" form) modifies a macro by appending additional text to it:
> string1 += [string2]
>
> After the append form:
> ...
> * If the macro exists and is an immediately-expanded macro, it appends a space and the
> evaluation of string2 to the value currently assigned to string1.
> ...

and this text survived more or less intact through to the final wording. There was nothing hidden about this.


Regarding this proposal, I am ambivalent on +:=. One reason I'm ambivalent is that in 25+ years of maintaining GNU make I don't ever recall anyone wanting the ability to add immediately expanded text to a deferred expansion variable. The other reason is that this same behavior can already be had, although it requires using two variables:

This:

  D = a
  D +:= $(VAR)

can be written:

  D = a
  I ::= $(VAR)
  D += $I

If it's really the case that you always want this behavior then that's annoying. But as I said, no one has ever asked for this so I question whether it's really something people need a lot. If people use it only occasionally then the two-variable version might even be preferred as more clearly understandable.

Another reason for my ambivalence is that these do exactly the same thing:

  A ::= b
  A += $(VAR)

and

  A ::= b
  A +:= $(VAR)

which makes the latter seem redundant to me.

The :::= operator seems wholly unnecessary. We have two types of variables and we have two assignment operators for them, which is sufficient. If there is a case to be made that putting an already-expanded value into a delayed expansion macro is useful then this:

  A :::= $(VAR)

can be replaced by:

  A =
  A +:= $(VAR)

or using the current POSIX standard with no changes:

  A =
  I ::= $(VAR)
  A += $I
(0005405)
mirabilos (reporter)
2021-07-10 21:26

On MirMake (inherited from OpenBSD make), it outputs 1.
(0005406)
joerg (reporter)
2021-07-15 14:51
edited on: 2021-07-15 14:52

In 37+ years of maintaining smake, I did never receive a request to implement
the := behavior from GNU make and no other make variant did implement that
behavior.

I therefore seriously doubt that there is a need for that GNU make feature.

(0005407)
joerg (reporter)
2021-07-17 10:35
edited on: 2021-07-22 15:13

As a result from the last teleconference, I decided that things
could only be understood, if all aspects of the behavior are
tested and documented.

There are four aspects with the various := implementations. Only
three of them may be tested by a makefile:

The first row is related to the behavior of recent bmake versions
and lets you see whether $$ is "expanded" to $ at the right side
of a := assignment, or whether $$ is forwarded as $$.
WARNING: The observed behavior here may also be influenced from
whether the make macro is expanded at use time or not, see gmake
notes below. So this test is only significant while comparing
different bmake versions.

The second row checks whether := results in an immediate expansion
of the right side before assigning the result to the macro. All
make implementations behave the same here, so this test is only
present for completeness.

The third row checks whether += appends using immediate expansion
or whether the appended text is expanded delayed at use time.
This is where GNU make is incompatible with all other make
implementations, as gmake behaves different with += if the macro
has been initially created with :=.

printf 'A = immediate\nB := $$A $A\nB += $A\nA = delayed\nall:\n\techo '\''$(B)'\''\n' | smake -s -f -

prints:
smake: WARNING: Nonportable ':=' assignment found for macro 'B' in line 2 col 4 of 'Standard in'
delayed immediate delayed

printf 'A = immediate\nB := $$A $A\nB += $A\nA = delayed\nall:\n\techo '\''$(B)'\''\n' | bmake-20150505 -s -f -

prints:
delayed immediate delayed

printf 'A = immediate\nB := $$A $A\nB += $A\nA = delayed\nall:\n\techo '\''$(B)'\''\n' | bmake-2020-04-03 -s -f -

prints:
$A immediate delayed

printf 'A = immediate\nB := $$A $A\nB += $A\nA = delayed\nall:\n\techo '\''$(B)'\''\n' | bmake-2021-06-21 -s -f -

prints:
delayed immediate delayed

printf 'A = immediate\nB := $$A $A\nB += $A\nA = delayed\nall:\n\techo '\''$(B)'\''\n' | gmake -s -f -

prints:
$A immediate immediate

What is not testable by this test but by looking at the internal
values of the variable via -p is whether make macros created via
:= are expanded at use time. Only gmake does not expand such macros
at use time. All other make implementation from above expand such
macros at use time.

As you see, the recent change in bmake, related to $$ expansion,
does definitely not result in gmake compatibility.

But the most recent bmake is by default compatible to the bmake
from 2015 again and it seems that at least for the last 20 years,
smake and bmake did implement identical behavior.

(0005408)
psmith (developer)
2021-07-18 03:22

> In 37+ years of maintaining smake, I did never receive a request to implement the := behavior from GNU make

In that case we can conclude is that this difference in behavior is of little or no concern to users, since they have not requested that either version be changed to support the other. That certainly doesn't *strengthen* the argument that we need to modify the standard to provide both models.

> There are four aspects with the various := implementations.

I'm sorry but I didn't understand the goal of these examples. They certainly do show that the behavior of := is different among different implementations, which is no surprise (at least not to me): that's why the := operator was NOT added to the standard and ::= was added instead. If BSD make users want the BSD make behavior of :=, they have := and they can continue to use it. If they want to change it in some way, for some reason, with or without an option, again that's up to the BSD make maintainers. Why is that a discussion for the POSIX committee?

This issue is proposing two NEW make operators: why should these new operators be added to the standard? The difference in behavior from the current set of available operators is obscure (as we've heard, no user has requested that either version of the behavior be changed) and there are ways to achieve the behavior these new operators provide using features available in the current POSIX standard, as shown above.


I've also read through the etherpad notes from 2021-07-15 and there seems to be confusion and false information there. In particular, it is not true that GNU make is not conforming to POSIX with respect to variable expansion. If someone thinks otherwise, please provide a POSIX-conforming makefile which exhibits incorrect variable expansion behavior in GNU make.
(0005409)
geoffclare (manager)
2021-07-19 08:43

> As you see, the recent change in bmake, related to $$ expansion,
> does definitely not result in gmake compatibility.

The statement about gmake compatibility was made in the context of how $$ is expanded. Obviously it is intended to indicate only that they have made $$ handling (more) compatible, not macro expansion in general. And it certainly is more compatible in that respect, as $$$$ on the right hand side of := now ends up being expanded to $$ instead of $.
(0005410)
steffen (reporter)
2021-07-19 12:30

..and especially there was no

> As you see, the recent change in bmake, related to $$ expansion,
> does definitely not result in gmake compatibility.

"recent change"; instead bmake added support for the notion, but did not make it its default, at least not in the set of makefiles that define the rules bmake uses by default in it portable incarnation.
(0005411)
joerg (reporter)
2021-07-19 13:41
edited on: 2021-07-19 14:01

Well, the bmake from NeBSD pkgsrc with a Changelog from April 3 2020 by
default does not expand $$.

Which version did you test?

(0005412)
steffen (reporter)
2021-07-19 13:55

I guess you were asking Geoff, but nonetheless ($PKG comes from "system"):

# Description: NetBSD make program
# URL: http://www.crufty.net/help/sjg/bmake.html [^]
# Maintainer: Steffen Nurpmeso, steffen at sdaoden dot eu

name=bmake
version=20210621
release=1
source=(http://www.crufty.net/ftp/pub/sjg/${name}-${version}.tar.gz) [^]

build() {
   cd ${name}

   sed -i'' -e '/cmd-interrupt$/d' -e '/var-op-shell$/d' unit-tests/Makefile

   mkdir -p build
   cd build

   sh ../boot-strap --with-default-sys-path=/usr/share/mk

   sh ../boot-strap --prefix=/usr \
      --with-mksrc=/usr/share/mk \
      --install-destdir="${PKG}" op=install

   chmod g-w "${PKG}"/usr/bin "${PKG}"/usr/share/mk
   rm -rf "${PKG}"/usr/share/man/cat1
   mkdir "${PKG}"/usr/share/man/man1
   cp ../bmake.1 "${PKG}"/usr/share/man/man1/
}
(0005413)
joerg (reporter)
2021-07-19 14:10

Thank you!

So it seems that I should edit my Note: 0005407 that a recent bmake
is fully aligned with smake again and the version 2020-04-03
was an exception. That makes things much easier...
(0005414)
geoffclare (manager)
2021-07-23 09:45
edited on: 2021-07-23 12:26

In yesterday's call we discussed whether, if we standardise BSD/bmake := as :::=, we would do so with or without $$ being preserved. Previously I had thought that if we went with the non-preserving behaviour, we could add some APPLICATION USAGE advising users to put $$$$ in values assigned with :::= in order to yield a single $ when expanded at use time. However, I now see that this only works for the simple case where a macro is used directly in a rule. If there are any intermediate := assignments, they each add another level of re-evaluation:
$ printf 'A := $$$$$$$$\nB := $(A)\nall:\n\techo $(B)\n' | bmake -f -
echo $
$

$ printf 'A := $$$$$$$$$$$$$$$$\nB := $(A)\nC := $(B)\nall:\n\techo $(C)\n' | bmake -f -
echo $
$

Worse still, if there are two rules that end up using the macro via different numbers of intermediate := assignments, it is impossible to put a string of $'s in the original value that will end up as a single $ in both rules (unless a single $ in the original value wouldn't have been expanded anyway).

This problem is presumably why .MAKE.SAVE_DOLLARS was added. The behaviour with it true seems greatly preferable to me, and I think the standard should require it for :::= (if we add it), although without specifying .MAKE.SAVE_DOLLARS. This would leave BSD/bmake implementors with two choices in order to conform:

1. Have :::= not be identical to :=, in that it is not affected by .MAKE.SAVE_DOLLARS but instead always preserves $$.

2. Have :::= be identical to :=, with .MAKE.SAVE_DOLLARS=true as the default (at least for makefiles that contain a .POSIX target).

I would like to hear what BSD/bmake implementors and users think about this.

(0005415)
joerg (reporter)
2021-07-23 17:27

The bmake Changelog mentions a modification that $$ was preserved
when using := starting from 2016-02-17 and the comment does not
include a hint that this was related to gmake.

Two days later, .MAKE.SAVE_DOLLARS was introduced and the default
was set to false to achieve compatibility with older versions.

Given that := did exist in smake and bmake since a longer time
without that $$ exception, it is obvious that not expanding $$
is only needed in very rare corner cases. The oldest version of
bsd make in the netbsd version control is from 1993 and already
supports the := assignment. Smake started to support := 10 years
later.
(0005421)
geoffclare (manager)
2021-07-29 08:17
edited on: 2021-07-29 08:17

Re: Note: 0005414 I agree that not expanding $$ is likely only needed in rare cases. However, I think the need to expand $$ is even rarer, and probably non-existent. The vast majority of uses of := work the same either way. Before the changes in 2016, the only reason anyone had to put $$$$ on the rhs of a := would be as a work-around for it being expanded twice (or more).

I assume the reason the default is not to preserve $$ is because there were existing makefiles where people has used this work-around, and defaulting to preserving $$ would break them. If $$ had always been preserved, those makefiles would not have needed to use $$$$ in the first place.

We should not make the same mistake with :::=

(0005423)
psmith (developer)
2021-07-29 18:07

Until someone can explain to me the advantage of adding Yet Another Assignment Operator to make, I'm not excited about spending effort adding it to GNU make. If there's behavior which is already implemented across all variants of make then that's obviously appropriate for standardization. If there's behavior which is used widely in makefiles, proving it has real utility for users, AND it provides behaviors which are not currently available in the standard, then that could be appropriate for standardization as well. Just because a facility _exists_ in a subset of variants of make, even if it has existed for a long time, is not by itself sufficient justification IMO.

I haven't seen evidence that the difference between the behavior of POSIX ::= and BSD make := is something that users care about and that makefiles want to take advantage of, such that it warrants a new operator. I've also pointed out above that the behavior of BSD make := can be obtained in terms of the existing POSIX ::= operator (although you do need to add an extra variable to do it).

- 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
2021-07-08 16:43 geoffclare Note Added: 0005393
2021-07-08 16:57 hvd Note Added: 0005394
2021-07-08 19:30 steffen Note Added: 0005395
2021-07-08 19:32 steffen Note Added: 0005396
2021-07-08 20:01 kre Note Added: 0005397
2021-07-08 20:21 steffen Note Added: 0005398
2021-07-08 20:34 steffen Note Added: 0005399
2021-07-08 21:15 kre Note Added: 0005400
2021-07-08 22:33 steffen Note Added: 0005401
2021-07-08 22:33 steffen Note Added: 0005402
2021-07-10 12:30 joerg Note Added: 0005403
2021-07-10 18:03 psmith Note Added: 0005404
2021-07-10 21:26 mirabilos Note Added: 0005405
2021-07-15 14:51 joerg Note Added: 0005406
2021-07-15 14:52 joerg Note Edited: 0005406
2021-07-17 10:35 joerg Note Added: 0005407
2021-07-18 03:22 psmith Note Added: 0005408
2021-07-19 08:43 geoffclare Note Added: 0005409
2021-07-19 12:30 steffen Note Added: 0005410
2021-07-19 13:41 joerg Note Added: 0005411
2021-07-19 13:55 steffen Note Added: 0005412
2021-07-19 14:01 joerg Note Edited: 0005411
2021-07-19 14:10 joerg Note Added: 0005413
2021-07-19 14:19 joerg Note Edited: 0005407
2021-07-22 15:13 joerg Note Edited: 0005407
2021-07-23 09:45 geoffclare Note Added: 0005414
2021-07-23 12:26 geoffclare Note Edited: 0005414
2021-07-23 17:27 joerg Note Added: 0005415
2021-07-29 08:17 geoffclare Note Added: 0005421
2021-07-29 08:17 geoffclare Note Edited: 0005421
2021-07-29 18:07 psmith Note Added: 0005423


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