Re: Automake vs. Automake-NG

[Stefano Lattarini]

On 08/21/2012 06:01 PM, Paolo Bonzini wrote:
> 
>>> Ok.  So the question I'd like you to ask yourself are:
>>>
>>> * Why does it make sense to request manual declaration of 'SUFFIXES'?
>>> * Does it make sense to do so in Automake, too?
> 
> And another question:
> 
> * Alternatively, could Automake-NG suggest converting suffix
>   rules to pattern rules
>
Yep, I will amend NG-NEWS to suggest that.

> so that the extra SUFFIXES entries are not necessary
> anymore?  Or even do that automatically in the Makefile.am ->
> Makefile.in conversion?
>
Oh no; Automake-NG does not specially recognize nor handle suffix rules
anymore.   It just passes them through.  In fact, I'm deliberately trying
to remove automake runtime processing whenever possible, moving it to
GNU make runtime instead.  In this case, since GNU make can with pattern
rules itself, without any extra '.SUFFIXES:' shenanigan, I just want to
suggest to use pattern rules where possible, and to explicitly initialize
$(SUFFIXES) otherwise (for example, when Gnulib-generated Makefile.am are
used, since they are tailored to Automake-NG and thus use suffix rules).

> [SNIP]

>>> All I'm saying is, do not release Automake-NG for public use until
>>> Automake can warn of all incompatible uses, or almost all.
>>>
>> As I said, I don't believe this would be actually doable.
> 
> Looking at GNU Smalltalk, I se, ase possible action items for Automake:
> 
> * warn for INCLUDES (vs. AM_CPPFLAGS)
>
Easy to do, and will do.  Maybe even for Automake 1.12.4 (it has been
deprecated in the documentation for ages already).

> * warn for unknown *_XYZFLAGS variables
>
I'm still unconvinced it would be a good idea to introduce this
incompatibility in Automake just for the sake of simplifying
transition to Automake-NG, sorry.

> * warn for treating _SOURCES entries with a custom unknown user
> extension as if they were header files
>
Ditto.

> (btw, why doesn't CAIRO_CFLAGS raise a warning)?
>
Probably because it's still handled at Automake runtime rather than
at make runtime.

> And as possible action items for Automake-NG:
> 
> * warn for suffix rules or otherwise do something about them
>
That would prevent an easy use of Automake-NG with Gnulib-generated
Makefile.am files.  Causing cascade issues in all of coreutils, m4,
grep, ...  A simple explanation in NG-NEWS will have to be enough.

> * fix BUILD_SOURCES fork bomb, perhaps warn about it in advance (though
> I'm not sure I understood the root cause here)
>
Absolutely.  Erroring out and making you tweak your build system is
acceptable, fork-bombing is not.

>>> You have to evaluate each case separately of course, but a single
>>> project has already shown several cases where Automake _could_ be
>>> improved this way.
>>>
>> Are you referring to the Smalltalk "port"?  If yes, I'm not seeing your
>> point honestly.  Care to elaborate?
> 
> See above.
> 
We'll have to agree to differ in most respects then.  Sorry.

Best regards,
  Stefano