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

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

On Sun, Aug 17, 2014 at 11:14:00AM +0000, Christos Zoulas wrote:
> In article <20140817101611.GQ965%roskakori.fi@localhost>,
> Jarmo Jaakkola  <jarmo.jaakkola%roskakori.fi@localhost> wrote:
> >And these are the three possible solutions I could come up with:
> > a) Retain full .NULL support.  We then need to specify how it
> >    interacts with the POSIX single suffix rules.  This would IMO get
> >    ugly and complicated.
> 
> I think that (a) is workable. Or we can wait for pattern rules, then
> deprecate .NULL.

What would the interaction rules then be?  But hold on a while before
answering, see below.

> >What should be done?  Are there some other solutions?

Inspired by Valery's email, I got thinking.  Conceptually, there is only
one case of "no (known) suffix".  The problem is, we cannot write the case
of "no suffix" explicitly.  Unless:
 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.

I think this would be the best.  The old .NULL could be removed and
there would be no need to think how it should work properly with
single suffix transformations.  People could also be directed to use
the replacement they need by the emitted parse error.  They could also
be informed that in case of "add a suffix" they will face another change
when pattern rules get implemented.

> >Do you mean that .NULL should support multiple suffixes?  Sounds a bit
> >hairy.
> 
> You could make .NULL take a list of suffixes and then check a suffix against
> the list. Wouldn't that work?
> 
> .NULL: .b .d

This wouldn't be without its problems.  In the case of "remove a suffix"
it would just add more crutches to a feature that is going away anyway.
For "add a suffix" we would need to handle the case where both ".b.x"
and ".d.x" exist.  Do we pretend "foo" is "foo.b" or "foo.d" to make
"foo.x"?  Also, what if "foo" and "foo.b" both exist?  The current
implementation would favor "foo", I think.  What if .b is before .d in
.SUFFIXES, and "foo" and "foo.d" exist?

-- 
Jarmo Jaakkola