Re: [PATCH] {master} compile: remove support for $(INCLUDES)

[Stefano Lattarini]

On 08/22/2012 10:28 PM, Eric Blake wrote:
> On 08/22/2012 09:12 AM, Stefano Lattarini wrote:
>> >From 54a49542d417850e646fefe7bad56546a2362449 Mon Sep 17 00:00:00 2001
>> Message-Id: <address@hidden>
>> From: Stefano Lattarini <address@hidden>
>> Date: Wed, 22 Aug 2012 16:40:15 +0200
>> Subject: [PATCH] compile: remove support for $(INCLUDES)
>>
>> It has already been deprecated in the manual and by warnings in the
>> 'obsolete' categories for ages (at least since 2003), in favour of
>> AM_CPPFLAGS.  Automake-NG has removed support for it already.
>>
>> So, by removing it in Automake 1.13, we will simplify the transition
>> path for people that want to switch to Automake-NG.
> 
> What a bummer for packages like libvirt that strive to be buildable from
> git on both RHEL 5 (requires INCLUDES, since automake 1.9.6 is still the
> current version there)
>
AM_CPPFLAGS is not supported in 1.9.6 ?!?  That sounds strange, and
disappointing ...

> as well as Fedora rawhide (where removing support
> for INCLUDES entirely will force the issue over to AM_CPPFLAGS).  It
> means I'll have to come up with some compatibility hacks in order to
> share one Makefile.am among both automake versions.
> 
> Or maybe I'll just give up and say that libvirt can no longer be
> bootstrapped on RHEL 5 (it can still be developed there, but only if you
> bootstrap somewhere else and then 'make dist' and develop on the
> distributed tarball).  At any rate, I'm fine taking the burden of trying
> to support cross-automake versioning in order to cater to the fact that
> enterprise systems are still stuck on ancient automake, but a little
> help from automake would make it easier.
>
About this patch, my opinion is more of a "meh"; that is, I don't care
either dropping support for $(INCLUDES) or keeping it, and I'd happily
put up with whichever consensus the community reaches.  If no consensus
is reached, I might play safe and keep the status quo (i.e., preserve
$(INCLUDES) support in 1.13, maybe removing it in 1.14, maybe keeping it
still).

> I'd much rather a mandatory noisy warning period before a feature is
> completely removed.
>
This would require a new category of warnings that are are unconditionally
show, regardless of strictness or any "-Wnone" option.  As usual, patches
welcome.

> Yes, you've warned, but the warning wasn't
> mandatory, so no one has been forced to come up with workarounds yet.
> It is only once people have the workarounds in place that it is safe to
> remove the feature; I think that argues that you can't remove INCLUDES
> until 1.14, but that 1.13 should make the warning unconditional.
>
I'd be happy to go this route, if someone is willing to provide the
patches, and if there is enough "community consensus".

> It would also be nice if you provided a feature that could be probed at
> m4 time in order to write a configure.ac that can then set an automake
> conditional, so that Makefile.am can then set either INCLUDES or
> AM_CPPFLAGS as appropriate within the two branches of the conditional.
> 
That sounds too tricky IMHO, a recipe for bad hacks.  Still, it might work
well *in some "selected" cases*, so I wouldn't refuse patches in that
direct a priori.

What I think we should do is actually making deprecations more smooth in
the future:

  1.11: no warning
    ->
  1.12: warning in the "obsolete" category
    ->
  1.13: unconditional warning
    ->
  1.14: explicit error with suggested workaround
    ->
  1.15: simply drop support altogether

Mea culpa here, because I've been often too eager to rush deprecations
into removals so far.

OTOH, I believe developers working on older systems should be ready to
install more recent developer tools once in a while.  You can't truly
expect not to update your Automake installation for 3, 4 years!

Regards,
  Stefano