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

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

In article <20140817141345.GS965%roskakori.fi@localhost>,
Jarmo Jaakkola  <jarmo.jaakkola%roskakori.fi@localhost> wrote:
>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.

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

>
>> >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?

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.


christos