[Issue 8 drafts 0001325]: Allow make to remake an included file
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1325 == Reported By:dmitry_goncharov Assigned To: == Project:Issue 8 drafts Issue ID: 1325 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Under Review Name: Dmitry Goncharov Organization: User Reference: Section:(section number or name, can be interface name) Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text:https://austingroupbugs.net/view.php?id=1325#c5066 == Date Submitted: 2020-02-09 17:17 UTC Last Modified: 2020-11-05 00:54 UTC == Summary:Allow make to remake an included file == Relationships ID Summary -- parent of 0001415 The text added as a result of Issue #13... == -- (0005099) dwheeler (reporter) - 2020-11-05 00:54 https://austingroupbugs.net/view.php?id=1325#c5099 -- The ability to remake included files is broadly useful, as demonstrated by the many "make" implementations that support this capability. Here's a specific example of a Makefile fragment using it (this example uses several GNU make capabilities that are missing from POSIX, but the point is to show that remaking included files *is* a capability people use): https://github.com/david-a-wheeler/make-booster . geoffclare: Thank you for creating this compromise text. I think it is absolutely *vital* that it not conflict with the very-widely-used GNU make implementation. The POSIX specification of "make" lacks many functionalities that are needed, and thus many people end up creating Makefiles specific to a specific implementation (e.g., GNU make). I hope that the POSIX specification will be extended to handle more situations. This is only one step towards that desirable result, but it seems like a good step forward. Issue History Date ModifiedUsername FieldChange == 2020-02-09 17:17 dmitry_goncharovNew Issue 2020-02-09 17:17 dmitry_goncharovName => Dmitry Goncharov 2020-02-09 17:17 dmitry_goncharovSection => (section number or name, can be interface name) 2020-02-09 18:29 shware_systems Note Added: 0004780 2020-02-10 13:27 joerg Note Added: 0004781 2020-02-10 13:28 joerg Note Edited: 0004781 2020-10-26 15:52 geoffclare Project Online Pubs => Issue 8 drafts 2020-10-26 15:53 geoffclare Note Added: 0005066 2020-10-26 15:54 geoffclare Page Number => (page or range of pages) 2020-10-26 15:54 geoffclare Line Number => (Line or range of lines) 2020-10-26 15:54 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1325#c5066 2020-10-26 15:54 geoffclare Status New => Resolved 2020-10-26 15:54 geoffclare Resolution Open => Accepted As Marked 2020-10-26 15:54 geoffclare version => Draft 1 2020-10-26 15:54 geoffclare Tag Attached: issue8 2020-10-26 16:54 nick Relationship added parent of 0001415 2020-10-26 16:57 rhansenNote Added: 0005068 2020-10-26 16:58 rhansenNote Edited: 0005068 2020-10-26 17:00 rhansenNote Edited: 0005068 2020-10-26 17:08 nick Note Added: 0005069 2020-10-26 17:08 nick Resolution Accepted As Marked => Reopened 2020-10-26 22:34 nick Status Resolved => Under Review 2020-10-27 10:09 geoffclare Note Added: 0005070 2020-10-27 13:09 joerg Note Added: 0005071
[Issue 8 drafts 0001325]: Allow make to remake an included file
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1325 == Reported By:dmitry_goncharov Assigned To: == Project:Issue 8 drafts Issue ID: 1325 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Under Review Name: Dmitry Goncharov Organization: User Reference: Section:(section number or name, can be interface name) Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text:https://austingroupbugs.net/view.php?id=1325#c5066 == Date Submitted: 2020-02-09 17:17 UTC Last Modified: 2020-11-04 22:53 UTC == Summary:Allow make to remake an included file == Relationships ID Summary -- parent of 0001415 The text added as a result of Issue #13... == -- (0005098) joerg (reporter) - 2020-11-04 22:53 https://austingroupbugs.net/view.php?id=1325#c5098 -- Re: https://austingroupbugs.net/view.php?id=1325#c5094 my impression is that you are missunderstanding the intention of https://austingroupbugs.net/view.php?id=1325#c5087 The intention of that text is to describe what may be done in a portable way. This of course cannot include rules related to an include file that appear after the include statement, since this would neither work with SunPro Make, nor with smake. The text in https://austingroupbugs.net/view.php?id=1325#c5087 describes the common denominator of smake, SunPro Make and GNU make. It describes makefile variants that would not work with all implementations as being non-compliant. Makefiles that make use of rules that appear after the related include statement, depend on a vendor specific enhancement. They are not forbidden, but rather based on non-portable extensions. If you believe that https://austingroupbugs.net/view.php?id=1325#c5087 depends on a required feature that is not or cannot be supported by GNU make, this would be a reason for a veto, but from what I can say, this does not apply. Issue History Date ModifiedUsername FieldChange == 2020-02-09 17:17 dmitry_goncharovNew Issue 2020-02-09 17:17 dmitry_goncharovName => Dmitry Goncharov 2020-02-09 17:17 dmitry_goncharovSection => (section number or name, can be interface name) 2020-02-09 18:29 shware_systems Note Added: 0004780 2020-02-10 13:27 joerg Note Added: 0004781 2020-02-10 13:28 joerg Note Edited: 0004781 2020-10-26 15:52 geoffclare Project Online Pubs => Issue 8 drafts 2020-10-26 15:53 geoffclare Note Added: 0005066 2020-10-26 15:54 geoffclare Page Number => (page or range of pages) 2020-10-26 15:54 geoffclare Line Number => (Line or range of lines) 2020-10-26 15:54 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1325#c5066 2020-10-26 15:54 geoffclare Status New => Resolved 2020-10-26 15:54 geoffclare Resolution Open => Accepted As Marked 2020-10-26 15:54 geoffclare version => Draft 1 2020-10-26 15:54 geoffclare Tag Attached: issue8 2020-10-26 16:54 nick Relationship added parent of 0001415 2020-10-26 16:57 rhansenNote Added: 0005068 2020-10-26 16:58 rhansenNote Edited: 0005068 2020-10-26 17:00 rhansenNote Edited: 0005068 2020-10-26 17:08 nick Note Added: 0005069 2020-10-26 17:08 nick Resolution Accepted As Marked => Reopened 2020-10-26 22:34 nick Status Resolved => Under Review 2020-10-27
Re: [Issue 8 drafts 0001325]: Allow make to remake an included file
On Wed, 2020-11-04 at 18:05 +0100, Joerg Schilling via austin-group-l at The Open Group wrote: > I am not sure whether I missed something, but I cannot see a method > that may work in a portable way and unless I missed something, I see > no new idea that makes things really better than what we are > currently discussing. In the paper I discuss the problems with the generated output and the advantages to avoiding it. > The problem I see is that the advanced method available with SunPro > Make does not seem to be supported by GNU make and the options > mentioned in the paper from above seem to be GCC specific and still > require a separate compiler call. They are technically not GCC-specific: clang also provides these options. But that support is not necessary: in the paper I go over a few alternatives to use if your compiler isn't capable of generating dependencies as a side-effect of compilation. Whatever process you use to generate the .d files is simply added to the compiler invocation rule. Yes, it means you may need to run the compiler twice but it still works and you have to run the compiler twice when using generated include files anyway. The built-in compiler support is simply an efficiency improvement, it's not a fundamental requirement.
Re: [Issue 8 drafts 0001325]: Allow make to remake an included file
On Wed, 2020-11-04 at 16:47 +, Geoff Clare via austin-group-l at The Open Group wrote: > Having read this, I'm now wondering why we are bothering to add > requirements for generating include files, if it is no longer the > recommended way of doing things. There are other uses for auto-generating included files: it does give you a bit of "meta-programming" capability and some flexibility to auto-generate rules that plain makefiles cannot. Implicit rules, and particularly POSIX suffix rules, are really not powerful enough to provide all the different types of templating you might want. However I don't know if this is sufficient justification for a change to POSIX. I wrote a post about this too: http://make.mad-scientist.net/constructed-include-files/ Looks like this post needs to be updated to note you don't need to use -include anymore as well :) > > This post obviously makes use of GNU make-specific features but I > > don't believe there's anything there that couldn't be also > > implemented in standard make. > > To improve efficiency it relies on the compiler having an option to > request creation of a dependency list at the same time as creating > the .o file. However, something similar is possible with standard c99 > by creating a .i file and then creating the .o and .d from that. Yes. But in any event, even if you do the simple thing and just run it twice you're no worse off since regenerated include files require running the compiler twice as well. > Here's a modified version of the proposed example that uses this new > technique. Note that you have to use "make -r" otherwise it uses the > default .c.o rule instead! The rules for a.o and b.o seem to be > needed by SunPro make but not by GNU make. > > .POSIX: > .SUFFIXES: .c .i .o To avoid using make -r you can clear the suffixes before defining new ones: .SUFFIXES: .SUFFIXES: .c .i .o
Re: [Issue 8 drafts 0001325]: Allow make to remake an included file
On Wed, 2020-11-04 at 10:48 +, Geoff Clare via austin-group-l at The Open Group wrote: > > - > > (0005094) psmith (developer) - 2020-11-03 15:23 > > https://austingroupbugs.net/view.php?id=1325#c5094 > > > > Regarding the change to page 2891 lines 97033-97035: > > It's there because GNU make uses re-execution. The re-executed make > doesn't know what targets the previous invocation updated, so it > doesn't know to treat them as already up-to-date. I understand. I need to stop thinking of the re-exec'd make and simply consider the entirety of the process. The real process GNU make undertakes is something like: 1. Read all makefiles. Don't error if they do not exist. 2. Consider all makefiles as goal targets and try to rebuild them. 3. If any rebuild, clear out all knowledge of all parsed makefiles and go to step 1 (GNU make does this via re-exec but that's not required of course). 4. If any required makefiles are missing, fail. 5. Build the normal goal targets. So, it's never the case that by the time you get to step #5, any makefile will be reconsidered: at that point all makefiles will be known to be up to date. > The aim here was to describe the cut-off-point where all include file > generation has been completed and after which the new contents of the > files is used. This cut-off-point needs to be before make starts the > "real work", i.e. starts the work to bring the first target operand, > or the first target make encounters if there are no operands, up-to- > date. Can we just say that? All include file regeneration is complete before make attempts to bring the first target_name operand, or the first target make encounters if no target is specified? > > In the portability text (second bullet), a portable workaround to > > using a macro defined in one included file in the include line of > > another, is to put the second include _inside_ the first included > > file instead of in the outer including makefile. > > Okay, that sounds like it is worth adding. Maybe something like: > > Include lines and rules for creating dynamic include files do not > depend on the contents of any earlier dynamic include file. For > example, defining a macro in a dynamic include file and using > that > macro in a later include line should be avoided (unless the later > include line is itself inside the dynamic include file). OK. > If adding "ddir" to the search path is achieved by means of an > extension (such as -I), then the requirement in the standard does not > apply to "ddir"; it only applies to the default search path. > > It is only the default search path that I see as a problem. If a > user explicitly wants a directory searched, then that implies they > know what's in that directory and will choose include file names with > that in mind. If there's a clash which causes their makefile to > behave differently than intended, that's the user's fault. Yes, exactly. > Sounds like we are in agreement with how GNU make should handle this > issue. It can prioritise specified search paths over remaking, but > not the default search path. I believe the currently proposed text > allows that, because specifying a search path involves using an > extension. OK, I'm OK with making this change to GNU make to meet the standard if needed. Thanks!
Re: [Issue 8 drafts 0001325]: Allow make to remake an included file
On Wed, 2020-11-04 at 12:01 +, Geoff Clare via austin-group-l at The Open Group wrote: > I haven't been able to come up with a common initial statement that > is preferable to just describing the two methods separately. So > unless someone else wants to give it a go, I suggest that I should > restructure that part along these lines: > > The make utility shall use one of the following two methods > to attempt to create the file or bring it up-to-date: > > 1. The "immediate remaking" method > > If make uses this method, any target rules or inference > rules for the pathname that were parsed before the include line > was parsed shall be used to attempt to create the file or to > bring it up-to-date before opening the file. > > 2. The "delayed remaking" method > > If make uses this method, no attempt shall be made to > create the file or bring it up-to-date until after the > makefile(s) have been read. During processing of the include > line, make shall read the current contents of the file, > if it exists, or treat it as an empty file if it does not exist. > Once the makefile(s) have been read, make shall use any > applicable target rule or inference rule for the pathname, > regardless of whether it is parsed before or after the include > line, when creating the file or bringing it up-to-date. This seems OK to me. I like the idea of using two separate sections; the process seems different enough that it's confusing to shoe-horn it into a single one.
Re: [Issue 8 drafts 0001325]: Allow make to remake an included file
Geoff Clare via austin-group-l at The Open Group wrote: > > I wrote a blog post about this which may be interesting: > > http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/ > > Having read this, I'm now wondering why we are bothering to add > requirements for generating include files, if it is no longer the > recommended way of doing things. I am not sure whether I missed something, but I cannot see a method that may work in a portable way and unless I missed something, I see no new idea that makes things really better than what we are currently discussing. The problem I see is that the advanced method available with SunPro Make does not seem to be supported by GNU make and the options mentioned in the paper from above seem to be GCC specific and still require a separate compiler call. The intention for POSIX however is to standardize portable solutions. This is why I believe that the current solution from bug 1325 is the right way to go in the close future. The method based on cc -E as distributed by the schily makefilesystem has been verified to be portable to virtually any platform - even to the Microsoft compiler, see the shell script conf/mkdep-msc.sh Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [Issue 8 drafts 0001325]: Allow make to remake an included file
> --
> (0005096) psmith (developer) - 2020-11-03 15:31
> https://austingroupbugs.net/view.php?id=1325#c5096
> --
> Apropos of the example given here: I just want to say that in the GNU
> project we have completely moved away from using rebuilt included makefiles
> as part of automatic prerequisite generation, as being (a) tricky, (b)
> impossible to make completely seamless, (c) inefficient, and (d) wholly
> unnecessary.
>
> I wrote a blog post about this which may be interesting:
> http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/
Having read this, I'm now wondering why we are bothering to add
requirements for generating include files, if it is no longer the
recommended way of doing things.
> This post obviously makes use of GNU make-specific features but I don't
> believe there's anything there that couldn't be also implemented in
> standard make.
To improve efficiency it relies on the compiler having an option to
request creation of a dependency list at the same time as creating
the .o file. However, something similar is possible with standard c99
by creating a .i file and then creating the .o and .d from that.
At first sight it also looked like it depended on $(wildcard ...) but
then I realised it could just use:
-include $(DEPFILES)
instead of:
include $(wildcard $(DEPFILES))
Here's a modified version of the proposed example that uses this new
technique. Note that you have to use "make -r" otherwise it uses the
default .c.o rule instead! The rules for a.o and b.o seem to be
needed by SunPro make but not by GNU make.
.POSIX:
.SUFFIXES: .c .i .o
OFILES = a.o b.o
pgm: $(OFILES)
c99 $(OFILES) -o pgm
a.o: a.i
b.o: b.i
.c.i:
c99 -E $< > $@
cfile=$<; dfile=$${cfile%.c}.d; \
{ \
set -o pipefail; \
printf '%s: %s ' $@ $<; \
LC_ALL=C sed -n \
'/^#[[:blank:]]*[[:digit:]]/s/.*"\([^"]*\.h\)".*/\1/p' $@ | \
LC_ALL=C sort -u | tr '\n' ' '; \
echo; \
} > "$$dfile"
.i.o:
c99 -c $<
-include $(OFILES:.o=.d)
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
[Issue 8 drafts 0001325]: Allow make to remake an included file
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1325 == Reported By:dmitry_goncharov Assigned To: == Project:Issue 8 drafts Issue ID: 1325 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Under Review Name: Dmitry Goncharov Organization: User Reference: Section:(section number or name, can be interface name) Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text: https://www.austingroupbugs.net/view.php?id=1325#c5066 == Date Submitted: 2020-02-09 17:17 UTC Last Modified: 2020-11-04 16:45 UTC == Summary:Allow make to remake an included file == Relationships ID Summary -- parent of 0001415 The text added as a result of Issue #13... == -- (0005097) joerg (reporter) - 2020-11-04 16:45 https://www.austingroupbugs.net/view.php?id=1325#c5097 -- Re: https://www.austingroupbugs.net/view.php?id=1325#c5096 The most advanced method has been introduced in January 1986 by SunPro Make. You put this line: .KEEP_STATE: or .KEEP_STATE: state-file-name into the Makefile and make then manages the include dependencies in a hidden way by setting the "SUNPRO_DEPENDENCIES=" environment to: SUNPRO_DEPENDENCIES="some/unique/path " with set to $@ for the current command. The compiler then (as a side-effect) writes the dependencies in make syntax into some/unique/path and SunPro Make collects all such output into the file .make.state or in state-file-name. This is safe and increases overall performance as it avoids a second compiler call. Together with changes to SunPro Make and the UNIX linker from around 1993, based on the environment SGS_SUPPORT=libmakestate.so.1, a callback interface in the linker delivers all needed information on path names of linked libraries. This completely closes all loopholes on dependencies that before typically have been in hierarchical makefile systems. Issue History Date ModifiedUsername FieldChange == 2020-02-09 17:17 dmitry_goncharovNew Issue 2020-02-09 17:17 dmitry_goncharovName => Dmitry Goncharov 2020-02-09 17:17 dmitry_goncharovSection => (section number or name, can be interface name) 2020-02-09 18:29 shware_systems Note Added: 0004780 2020-02-10 13:27 joerg Note Added: 0004781 2020-02-10 13:28 joerg Note Edited: 0004781 2020-10-26 15:52 geoffclare Project Online Pubs => Issue 8 drafts 2020-10-26 15:53 geoffclare Note Added: 0005066 2020-10-26 15:54 geoffclare Page Number => (page or range of pages) 2020-10-26 15:54 geoffclare Line Number => (Line or range of lines) 2020-10-26 15:54 geoffclare Final Accepted Text => https://www.austingroupbugs.net/view.php?id=1325#c5066 2020-10-26 15:54 geoffclare Status New => Resolved 2020-10-26 15:54 geoffclare Resolution Open => Accepted As Marked 2020-10-26 15:54 geoffclare version => Draft 1 2020-10-26 15:54 geoffclare Tag Attached: issue8 2020-10-26 16:54 nick Relationship added parent of 0001415 2020-10-26 16:57 rhansenNote Added: 0005068 2020-10-26 16:58 rhansenNote Edited: 0005068 2020-10-26 17:00 rhansenNote Edited: 0005068 2020-10-26 17:08 nick Note Added: 0005069 2020-10-26 17:08 nick Resolution Accepted As Marked => Reopened 2020-10-26 22:34 nick Status Resolved => Under Review 2020-10-27 10:09
Re: [Issue 8 drafts 0001325]: Allow make to remake an included file
Geoff Clare wrote, on 04 Nov 2020: > > > > If a target rule or inference rule for the pathname has been parsed > > > before the include line is parsed, make shall use the rule to attempt > > > to create the file or to bring it up-to-date. > > > > I don't think this is quite correct. In GNU make, anyway, it's not > > required that an inference rule parsed before the include line is parsed > > will always be used. If a target rule, or a different inference rule, is > > defined after the include line then that will be used instead. > > I see your point. I was trying to find a way to make an initial single > statement that was true for both methods, but maybe that's not possible. > The text may need to separate the two descriptions entirely. I'll give > it some more thought. I haven't been able to come up with a common initial statement that is preferable to just describing the two methods separately. So unless someone else wants to give it a go, I suggest that I should restructure that part along these lines: The make utility shall use one of the following two methods to attempt to create the file or bring it up-to-date: 1. The "immediate remaking" method If make uses this method, any target rules or inference rules for the pathname that were parsed before the include line was parsed shall be used to attempt to create the file or to bring it up-to-date before opening the file. 2. The "delayed remaking" method If make uses this method, no attempt shall be made to create the file or bring it up-to-date until after the makefile(s) have been read. During processing of the include line, make shall read the current contents of the file, if it exists, or treat it as an empty file if it does not exist. Once the makefile(s) have been read, make shall use any applicable target rule or inference rule for the pathname, regardless of whether it is parsed before or after the include line, when creating the file or bringing it up-to-date. Additionally in this case, [...] If the pathname is relative, [...] -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [Issue 8 drafts 0001325]: Allow make to remake an included file
> -- > (0005094) psmith (developer) - 2020-11-03 15:23 > https://austingroupbugs.net/view.php?id=1325#c5094 > -- > Thank you for all your effort Geoff! I like this version very much. A few > notes / clarifying questions: > > Regarding the change to page 2891 lines 97033-97035: is this because smake > / SunPro make will re-consider and re-build included makefiles if they > appear as prerequisites to another target? GNU make never reconsiders a > target after it's been considered, regardless of whether or not it's an > included file. It's there because GNU make uses re-execution. The re-executed make doesn't know what targets the previous invocation updated, so it doesn't know to treat them as already up-to-date. > Regarding this: > > > If a target rule or inference rule for the pathname has been parsed > before the include line is parsed, make shall use the rule to attempt to > create the file or to bring it up-to-date. > > I don't think this is quite correct. In GNU make, anyway, it's not > required that an inference rule parsed before the include line is parsed > will always be used. If a target rule, or a different inference rule, is > defined after the include line then that will be used instead. I see your point. I was trying to find a way to make an initial single statement that was true for both methods, but maybe that's not possible. The text may need to separate the two descriptions entirely. I'll give it some more thought. > For the section "Additionally in this case, the new contents of the file, > if it is successfully created or updated, shall be used when processing > rules for the following targets after the makefile(s) have been read:" > followed by the bullet points, can you give me a hint as to what we are > trying to ensure or prevent by this text? By listing these specific things > I worry that I will overlook something that we do today that will become > invalid as a result of this text. Is there a difference we are trying to > surface between how included files normally work, and these rebuilt > included files work? The aim here was to describe the cut-off-point where all include file generation has been completed and after which the new contents of the files is used. This cut-off-point needs to be before make starts the "real work", i.e. starts the work to bring the first target operand, or the first target make encounters if there are no operands, up-to-date. The third bullet is because make has to (recursively) bring the prerequisites of this first target up-to-date before the target itself. Perhaps there is a better way to achieve this aim - I'm open to suggestions. > Is it not sufficient to say something like, the new > contents of the file will be used when processing rules that appear after > the included file as if the text had appeared in the makefile? Surely that's not true for GNU make. I thought it would use old include file contents when processing a later rule that is used to generate another include file. > In the portability text (second bullet), a portable workaround to using a > macro defined in one included file in the include line of another, is to > put the second include _inside_ the first included file instead of in the > outer including makefile. This can be less convenient in some situations > but it will work in all situations. Okay, that sounds like it is worth adding. Maybe something like: Include lines and rules for creating dynamic include files do not depend on the contents of any earlier dynamic include file. For example, defining a macro in a dynamic include file and using that macro in a later include line should be avoided (unless the later include line is itself inside the dynamic include file). (the only difference is the added part in parentheses). > > In the portability text I don't understand the need for the third > bullet...? It was an attempt at guidance on how to prevent re-execution-ad-infinitum. > In the make examples text I am not sure what the point of the initial > -include line is... why is that needed in this situation? So that SunPro make knows the prerequisites for the include file (if it already exists) when it processes the second include line. > It also seems > that each target will list all its prerequisites twice, although of course > that's not a problem. You might also consider using the make variable > $(CC) in these examples rather than hardcoding the c99 value. It's intended as an updated version of the previous example, which uses c99. I would not object to changing both examples to use $(CC). > Regarding the issue of searching of include files, I don't agree with this > as written. I do understand the problem you're addressing, and I have no > problems making some types of changes to GNU make to meet the standard, but > the
