Re: Make and makefile bugs (PRs 49085, 49086, 49087)

[christos%astron.com@localhost (Christos Zoulas)]

In article <20140817184244.GU965%roskakori.fi@localhost>,
Jarmo Jaakkola  <jarmo.jaakkola%roskakori.fi@localhost> wrote:
>On Sun, Aug 17, 2014 at 03:17:30PM +0000, Christos Zoulas wrote:
>> In article <20140817141345.GS965%roskakori.fi@localhost>,
>> Jarmo Jaakkola  <jarmo.jaakkola%roskakori.fi@localhost> wrote:
>> > d) Replace .NULL with .NULL.xx.  This would look just like a regular
>> >    double suffix transformation rule and that's what it would be.
>> >    We just write the "" as ".NULL".  The reverse of ".xx.NULL" would
>> >    not exist, because we have the standard ".xx".  Or perhaps
>> >    ".NOSUFFIX.xx", as null is already way too overloaded.  The target
>> >    name would also fall into the POSIX "reserved for implementation
>> >    extensions" namespace.
>> 
>> Sure, but I don't see how this is better. No matter what string you choose
>> to represent as the empty suffix, it could be used in real life. Yes, this
>> is far fetched, but I think this is why the designers of pmake invented
>> .NULL (so that you can choose a strng that you don't use as the empty 
>> suffix).
>
>Ah yes, of course.  In some ways ".NOSUFFIX.xx:" would not be any
>different from ".yy.xx:", if you consider it as a plain suffix rule.
>I was thinking it as more of a completely new special target, which
>just happens to look exactly a suffix rule would, if ".NOSUFFIX"
>stood for "".
>    .SUFFIXES: .foo
>    .NOSUFFIX.foo:
>        commands
>Note that .NOSUFFIX would not be added as a valid suffix in this case.
>This would be analoguous to ".PATH.foo:", which happens to look like
>a transformation rule, but there's actually no way of using it as such.
>Perhaps this is actually what you were thinking in your first mail
>with the ".NULL.gz:" rule?
>
>Perhaps it can even be implemented so that it can be made a regular
>suffix by adding it to .SUFFIXES by leaving it out of the special target
>list in parse.c and implementing the whole thing entirely
>in Suff_ParseTransform().
>
>Or just in case we could make it customisable as
>    .NOSUFFIX: .foo  # Hmm, where have I seen this before ;)
>The feature would be disabled unless explicitly asked for and
>the recommendation would be to use ".NOSUFFIX: .NOSUFFIX" if enabled.
>
>But hear me out.  As you've probably gathered by now, I'm strongly of
>the opinion that the "remove a suffix" functionality needs to be removed
>from this feature, no matter what is is called.  It is a true subset
>of a standard feature and supporting both would be an unnecessary
>complication.  And let's not talk about how dirty a hack it is
>to overload the regular double suffix rules for this functionality.
>(I would make it an error to specify ".NOSUFFIX: .foo" and
>".SUFFIXES: .foo" simultaneously)  Usually I favor backwards
>compatibility but in this case I would forgo it.
>
>Modifying the .NULL special target to only support "add a suffix"
>functionality would lead to possibly subtly broken makefiles.  Changing
>the name allows for safe modification, because the old feature can be
>made an error with instructions to either use single suffix
>transformations or .NOSUFFIX.
>
>Changing the behavior would also relieve us from the trouble of finding
>a working interaction with the single suffix rules.  Here are at least
>some of the things that would need a solution.
>
>What should happen with the following makefile for
>"touch foo.b; make foo.a"?  Should commands 1 or 2 be run?
>Does the ordering of .SUFFIXES or the rules have significance?
>Does it make sense that ".c.a:" can now be used as a substitute for
>".c:"?
>
>    .SUFFIXES: .a .b .c
>    .NULL: .a
>    .b:
>        commands1
>    .b.a:
>        commands2
>    .c.a:
>        commands3
>
>While we are at it, what if the following quotation is added to
>the makefile and the previous command is followed up with "make foo.d"?
>It would first drop the .b suffix and then add .d.  The ".NOSUFFIX"
>solution is by no means invulnerable to this, so we should know how
>to deal with this possibility.
>
>    .SUFFIXES: .d
>    .a.d:
>        commands4
>
>> I am sorry, but I've lost track of the case we are trying to fix. The
>> single suffix rule already works (see .c: in sys.mk). The way .NULL works
>> is kind of strange (I've even forgotten how it worked until you reminded
>> me), but if documented I think it is adequate. It all becomes a moot point
>> if we have suffix rules which are cleaner and better.
>             ITYM: pattern (for those just tuning in)
>
>No problem.  Turned out be quite a multi-faceted issue this one.
>Yes, single suffix rules work, as long as you don't use .NULL.
>
>The initial problem was that they stop working, if .NULL is used.
>Referring to the makefile example above, the ".b:" rule would not be
>used but ".b.a:" would be used instead.  If the ".b.a:" rule did not
>exist, making "foo" from "foo.b" would no longer work even if ".b:" did
>exist.
>
>That is the bug, I'm hoping for this discussion to find the best
>way to squash it.  I think that an extension should not so completely
>break standard behavior.  First I just ripped it all out, because I had
>incompletely understood what .NULL was used for and thought that
>the single suffix rules would completely cover it.  You educated me on
>the aspect I had missed.  During this discussion I've learned that
>the syntax and complete semantics of the .NULL special target are:
>
>    .NULL: .s1
>
>     1) "remove a suffix" aspect: if the target "foo" is needed,
>        the rule ".s2.s1:" can be used if the file "foo.s2" exists.
>     2) "add a suffix" aspect: if the target "foo.s2" is needed,
>        the rule ".s1.s2:" can be used, if the file "foo" exists.
>
>Because aspect 1 is a true subset of standard behavior available with
>a different syntax and aspect 2 overloads standard behavior with
>counter-intuitive extra semantics, I'm now suggesting that .NULL be
>replaced with either of:
>
>    .NOSUFFIX.s2:
>        commands
>
>    Suffix transformation from "" to ".s2".
>
>or
>
>    .NOSUFFIX: STANDIN
>    STANDIN.s2:
>
>    Suffix transformation from "" to ".s2".  STANDIN can be anything
>    that is not a suffix listed in .SUFFIXES.  .NOSUFFIX is recommended.
>
>This will break backwards compatibility in an obvious and safe way and
>allow for the removal of the duplicated features.
>
>You are partial to retaining the .NULL feature as it was and just fix
>the original problem.  This would also necessitate specifying how
>the overlap between aspect 1 and the single suffix rules is handled.
>
>I think that summarises this thread so far.  Either way, the changes in
>the patches are so extensive that I have to write new code in any case
>if you want to use the patches.  So don't let that weigh in
>the consideration.

I am partial for leaving it (.NULL) alone, documenting the existing
behavior, and getting rid of it when we have pattern rules. This
way we get one flag day, not two and we avoid unnecessary work. If
you are using .NULL on the same suffix as a single suffix rule you
get what's deserved^Wdocumented.

christos