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