[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefano Lattarini
Subject: Re: [PATCH] {master} compile: remove support for $(INCLUDES)
Date: Wed, 22 Aug 2012 23:52:48 +0200

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

> 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

> 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 that can then set an automake
> conditional, so that 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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]