Paul Smith via austin-group-l at The Open Group <austin-group-l@opengroup.org>
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/'
