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

[Jarmo Jaakkola <jarmo.jaakkola%roskakori.fi@localhost>]

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.

-- 
Jarmo Jaakkola