0001471: Add an orthogonal interface for immediate macro expansion definitions to make

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).

(0005440) Don Cragun (manager) 2021-08-12 15:19 edited on: 2021-08-12 15:25	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 delayed-expansion macro (replacing any previous definition of the macro named by string1): <tt>string1 :::= [string2]</tt> by immediately expanding macros in string2, if any, before assigning the value. On page 2895 line 97310, change: The macro $$ shall be replaced by the single character '$'. to: The string "$$" shall be replaced by the single character '$', except during the immediate expansion performed for the :::= operator, where it shall be left unmodified. On page 2910 line 97956, change: Therefore, the standard developers opted to require a new operator "::=" with specific semantics; this operator has semantics closest to the GNU make implementation of ":=", where '$' occurring in the immediate expansion of string2 are not further expanded in subsequent use of the macro, and it was felt that other implementations could easily support the required semantics. to: Therefore, the standard developers opted to require two new operators, "::=" and ":::=", with specific semantics; the "::=" operator has semantics closest to the GNU make implementation of ":=", where '$' occurring in the immediate expansion of string2 are not further expanded in subsequent use of the macro, and the ":::=" operator has semantics closest to the BSD make and smake implementations of ":=", where immediate expansion is performed when assigning to a delayed-expansion macro and "$$" is preserved. It was felt that other implementations could easily support the required semantics.

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
2021-08-12 15:19	Don Cragun	Note Added: 0005440
2021-08-12 15:20	Don Cragun	Final Accepted Text	=> See Note: 0005440.
2021-08-12 15:20	Don Cragun	Status	New => Resolved
2021-08-12 15:20	Don Cragun	Resolution	Open => Accepted As Marked
2021-08-12 15:20	Don Cragun	Tag Attached: issue8
2021-08-12 15:23	Don Cragun	Note Edited: 0005440
2021-08-12 15:25	Don Cragun	Note Edited: 0005440
2021-08-16 11:13	geoffclare	Status	Resolved => Applied
2021-08-19 11:05	geoffclare	Relationship added	related to 0001513
2024-06-11 09:12	agadmin	Status	Applied => Closed

Aardvark Mark IV