Re: unesthetic build commands generated by automake

[Alexandre Duret-Lutz]

>>> "Ralf" == Ralf Corsepius <address@hidden> writes:

[...]

 Ralf> Folks from the 2. community typically will apply custom make-rules and
 Ralf> will not care about portability.

So they just have to say -Wno-portability.  I fail to see what's
the problem with this.  It costs nothing.

However it costs a lot to let this be the default.  People don't
realize they write unportable Makefiles, and then complains that
Automake is a crap that doesn't achieve its claimed goal (ok,
that might be true, but in other areas).  It's frequent to get
bug reports about broken Makefiles just because people use
%-rules.  -Wno-portability as a default is confusing.  It's
hiding errors.

-Wportability shoud be the default.  It's sane.  It matches
Automake's goals.  It can be disabled in one line, while still
being compatible with 1.7.x.  

Besides it's not only a portability issue: Automake understands
.-rules but it doesn't understand %-rules, therefore it should
warn about the latter so people *know* something didn't work as
they expected.  (By "understand" I mean that Automake will take
appropriate actions to honor user-supplied .-rules when
computing derivation for source files.)

We already discussed all this in the past, I find frustrating to
waste time arguing this again.  

[...]

 >> I've tought about this too, but came to the conclusion it was
 >> impossible.
 Ralf> Well, it might not be possible in all cases of gmake-style
 Ralf> pattern-rules, but it probably is possible in a large subset of them.

I agree.  That means Automake should be able to decide which
%-rules are transformable and which %-rules aren't.  I don't
know how to do that, though.  If someone want to implement this,
that would be great [*].

Right now, Automake does not support %-rules, so it should warn
against their use.

[...]

[*] In fact it's also something we should do with chained .-rules too.
    Some make implementations are unable to chain .-rules, unless
    you specify the chain as list of dependencies explicitely.  (Only
    one step in the chain can be implicit.)
-- 
Alexandre Duret-Lutz