Re: make pattern rules (was: Re: [Issue 8 drafts 0001325]: Allow make to remake an included file)
Joerg Schilling wrote, on 09 Nov 2020: > > Geoff Clare via austin-group-l at The Open Group > wrote: > > > Paul Smith wrote, on 07 Nov 2020: > > > > > > Unless we are proposing pattern rules for inclusion in POSIX, [...] > > > > This was proposed in 2011 in bug 513, which is still open. > [...] > > Do you believe we have a chance to get to a text for Issue-8? As with any enhancement request that doesn't need a sponsor, all it needs is for someone to propose some suitable, detailed wording changes and for those changes to be accepted (perhaps after some modifications) in a teleconference. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: make pattern rules (was: Re: [Issue 8 drafts 0001325]: Allow make to remake an included file)
On Mon, 2020-11-09 at 14:16 +0100, Joerg Schilling wrote: > Paul Smith via austin-group-l at The Open Group < > austin-group-l@opengroup.org> wrote: > My idea is to start with a subset of the features of the original > implementation and to add some commonly *agreed* new features. Sure. > > I don't understand the distinction you're trying to draw between > > "disabled" and "deleted". Regardless, if you define a pattern rule > > with no commands then the previous pattern is gone and cannot be > > "re- > > enabled", so I think "deleted" is the correct term. > > Well, the fact that gmake still lists a "deleted" rule with gmake -p > is confusing users. I don't agree: it tells users that someone deleted that rule which I think is a useful thing to know. It's clear from the fact that no commands are shown, that this pattern cannot be used. > > Yes, that could be done. > > > > It's different than MAKEFLAGS += -r, however, because the latter is > > guaranteed to only delete the _built-in_ rules. This is almost > > always what the user wants. > > As mentioned before: internal rules need to be parsed before reading > the users Makefile, so a line in the form > > MAKEFLAGS += -r > > in the users Makefile is inefficient unless you ignore the rules for > the precedence of definitions that are in POSIX. I'm afraid I don't see the issue. It's not hard to keep a flag in any default rule specifying that it was created as a default, and either delete them all or just ignore them when searching rules, if they are disabled. Or, depending on the implementation, you can keep the default rules in a separate list and not search that list if the default rules are disabled. There are multiple implementation possibilities, which are not inefficient. > > Having "%:%" delete ALL the existing pattern rules is problematic > > because it relies on a specific ordering of appearance in > > makefiles. I'm sure such a feature would lead to a lot of head- > > scratching followed by cursing once a stray "%:%" pattern was > > discovered down in the bowels of the makefile system. > > Given that pattern rules _are_ based on the concept of a specific > ordering, this is a perfect enhancement. I disagree. The thing that users want is to remove the built-in rules. I see no reason why we should force them to add this special line as the first thing in their makefile to be sure they don't accidentally remove their own pattern rules. We don't require people to set .SUFFIXES: as the first thing in their makefile, before they define any suffix rules, for example. > > I would prefer to use a special target which forced all built-in / > > system rules (only) to be dropped, something like: > > > > .NOBUILTINS: > > This may be a useful potential enhancement, but this would still > differ from > > $make -r Since we are making it up there's no reason that it needs to differ from "make -r": we can just say that it doesn't :). > since .NOBUILTINS: would only affect rules from the internal > makefile, but not disable macro defitions. "make -r" does not disable macro definitions either. The standard says: > -r > Clear the suffix list and do not use the built-in rules. That does not mention macros anywhere, and in fact GNU make does not remove default macro definitions when given -r. This is the expected behavior because often makefiles will use the default macro definitions when defining their own rules, even if they are invoked with "make -r".
Re: make pattern rules (was: Re: [Issue 8 drafts 0001325]: Allow make to remake an included file)
Paul Smith via austin-group-l at The Open Group wrote: > Unless we are proposing pattern rules for inclusion in POSIX, which I > personally would be in favor of since they are much more useful than > suffix rules, perhaps we should move the discussion to a different > list? I would like to do this, but I am of course not willing to have any potential incompatible changes from GNU make. > On Fri, 2020-11-06 at 13:25 +0100, Joerg Schilling wrote: > > > I'm not sure where the idea that pattern rules are immutable comes > > > from: in GNU make any pattern rule can be overwritten at any time, > > > including the default pattern rules. > > > > This is how pattern rules have been defined when they appeared in > > SunPro Make in January 1986. > > Well, it's not how pattern rules in GNU make work. > > > The fact that gmake overwrites existing pattern rules is not > > sufficient (as it does not permit to remove them) > > That is not the case. You can absolutely remove them. The accepted way on UNIX for copying ideas from other implementations is to create a compatible clone with no "incompatible enhancements". My idea is to start with a subset of the features of the original implementation and to add some commonly *agreed* new features. This could be new features to remove single pattern rules or all pattern rules. > I don't understand the distinction you're trying to draw between > "disabled" and "deleted". Regardless, if you define a pattern rule > with no commands then the previous pattern is gone and cannot be "re- > enabled", so I think "deleted" is the correct term. Well, the fact that gmake still lists a "deleted" rule with gmake -p is confusing users. I just verified that gmake in fact correctly adds a new pattern rule with the same patterns of a deleted one to the end of the list. > Yes, that could be done. > > It's different than MAKEFLAGS += -r, however, because the latter is > guaranteed to only delete the _built-in_ rules. This is almost always > what the user wants. As mentioned before: internal rules need to be parsed before reading the users Makefile, so a line in the form MAKEFLAGS += -r in the users Makefile is inefficient unless you ignore the rules for the precedence of definitions that are in POSIX. > Having "%:%" delete ALL the existing pattern rules is problematic > because it relies on a specific ordering of appearance in makefiles. > I'm sure such a feature would lead to a lot of head-scratching followed > by cursing once a stray "%:%" pattern was discovered down in the bowels > of the makefile system. Given that pattern rules _are_ based on the concept of a specific ordering, this is a perfect enhancement. People who may get problems with that, are obviously using unplanned Makefiles. > I would prefer to use a special target which forced all built-in / > system rules (only) to be dropped, something like: > > .NOBUILTINS: This may be a useful potential enhancement, but this would still differ from $make -r since .NOBUILTINS: would only affect rules from the internal makefile, but not disable macro defitions. 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: make pattern rules (was: Re: [Issue 8 drafts 0001325]: Allow make to remake an included file)
Geoff Clare via austin-group-l at The Open Group wrote: > Paul Smith wrote, on 07 Nov 2020: > > > > Unless we are proposing pattern rules for inclusion in POSIX, [...] > > This was proposed in 2011 in bug 513, which is still open. the problem with this bug report is that I got the impression, it started with the wrong intention. The important point is that you need pattern rules if you like to put compilation results into platform specific sub-directories. I like to get pattern rules into the standard by only requiring a subset of what has been available since January 1986. The documentation is currently on page 30 of the man page: http://schilytools.sourceforge.net/man/man1/make.1s.html I would only standardize the form: tp%ts: dp%ds rule and mention tp%ts: [dependency ...] dp%ds [dependency ...] rule only as a potential enhancement that is not part of the standard. Smake e.g. currently only supports: tp%ts: dp%ds rule and tp%ts: rule BTW: this reminds me that I need to add documentation for: tp%ts: rule Note that the behavior of SunPro Make was not changed since 1986 with regards to pattern matching rules. Do you believe we have a chance to get to a text for Issue-8? 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: make pattern rules (was: Re: [Issue 8 drafts 0001325]: Allow make to remake an included file)
Paul Smith wrote, on 07 Nov 2020: > > Unless we are proposing pattern rules for inclusion in POSIX, [...] This was proposed in 2011 in bug 513, which is still open. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
make pattern rules (was: Re: [Issue 8 drafts 0001325]: Allow make to remake an included file)
Unless we are proposing pattern rules for inclusion in POSIX, which I personally would be in favor of since they are much more useful than suffix rules, perhaps we should move the discussion to a different list? On Fri, 2020-11-06 at 13:25 +0100, Joerg Schilling wrote: > > I'm not sure where the idea that pattern rules are immutable comes > > from: in GNU make any pattern rule can be overwritten at any time, > > including the default pattern rules. > > This is how pattern rules have been defined when they appeared in > SunPro Make in January 1986. Well, it's not how pattern rules in GNU make work. > The fact that gmake overwrites existing pattern rules is not > sufficient (as it does not permit to remove them) That is not the case. You can absolutely remove them. > and it is a non-compliance related to the original definition so > this modification from gmake causes unpredictable behavior. There is non-compliance with the POSIX standard. There are differences of implementation in areas that are not covered by the standard. There is no such thing as non-compliance with areas that are not covered by the standard. > Well after some searching (documentation could be better), I > discovered that gmake seems to disable (not to delete) pattern rules > if a rule with the same pattern but no command is defined. This is > not compliant to the definition of how pattern rules work. I don't understand the distinction you're trying to draw between "disabled" and "deleted". Regardless, if you define a pattern rule with no commands then the previous pattern is gone and cannot be "re- enabled", so I think "deleted" is the correct term. I think the docs are pretty clear: https://www.gnu.org/software/make/manual/html_node/Canceling-Rules.html > This is non-compliant behavior Pattern rules are not part of the POSIX standard, so "non-compliant behavior" is not an appropriate term. I'm happy to discuss incompatibilities between SunPro make/smake and GNU make as long as the discussion proceeds from a position that they are two co-equal implementations each with their own long history and (certainly in the case of GNU make) vast user bases that rely on the existing behaviors. However, I don't have the energy for discussions that begin with the premise that everything that exists in SunPro make/smake is canonical and any behavior in GNU make that differs from that is "non-compliant". > The series: > > %.o: %.c > echo some command > > %.o: %.c > > could be defined to require to completely remove the first definition > from the chain of pattern rules. That is already the way GNU make works. Although I don't know what you mean by the "first definition"; there can only be one instance of a given pattern rule (note, not one instance of a given pattern _target_; obviously many pattern rules may be defined with the same target). > As a result, the series: > > %.o: %.c > echo some command > > %.o: %.c > > %.o: %.c > echo some new command > > could be defined as to first define a pattern rule, then to > completely remove it from the chain of pattern rules and to finaly > add a new rule with a different command to the current end of the > pattern rule chain, without being completely incompatible to the > existing pattern rule specs. There is no single "spec" for pattern rules, there is only how SunPro make handles pattern rules and how GNU make handles pattern rules. In GNU make there's no need to delete the pattern rule before you define a new one. You just define the new one and it replaces the existing one. I don't see the point in requiring people to delete the pattern rule first. What does that buy you? > To fix this problem, the nonsense pattern with no command definition: > > %: % > > could be defined as the method to completely remove all existing > pattern rules from the current chain of pattern rules. Yes, that could be done. It's different than MAKEFLAGS += -r, however, because the latter is guaranteed to only delete the _built-in_ rules. This is almost always what the user wants. Having "%:%" delete ALL the existing pattern rules is problematic because it relies on a specific ordering of appearance in makefiles. I'm sure such a feature would lead to a lot of head-scratching followed by cursing once a stray "%:%" pattern was discovered down in the bowels of the makefile system. Possibly even accidentally as the result of a variable expanding to empty unexpectedly... A number of the enhancements to GNU make are intended to reduce the reliance on order of definition as much as possible. Users do want and rely on these enhancements. I would prefer to use a special target which forced all built-in / system rules (only) to be dropped, something like: .NOBUILTINS: This would provide the identical behavior as "make -r", but without modifying MAKEFLAGS. This seems like something that could easily be added to the standard as well, without even considering pattern
