Re: Removal of INCLUDES in favour of AM_CPPFLAGS

[Peter Rosin]

Hi Stefano,

On 2013-02-01 10:35, Stefano Lattarini wrote:
> On 02/01/2013 09:45 AM, Peter Rosin wrote:
>> From NEWS in the master branch:
>>
>>   - Support for the long-obsolete $(INCLUDES) variable has
>>     been finally removed, in favour of the modern equivalent
>>     $(AM_CPPFLAGS).
>>
>> Why is this removal important? It forces changes to a hundred
>> (or so) Makefiles in *one* project I'm involved with. The fact
>> that AM_CPPFLAGS is AC_SUBSTed by the project and used mostly
>> for "global" flags and INCLUDES mostly for "local" stuff makes
>> for a pretty useful separation. But in quite a few of those
>> Makefiles, AM_CPPFLAGS (as AC_SUBSTed by configure) is augmented
>> via "AM_CPPFLAGS +=" constructs. I'm not at all confident that
>> I will be able to convert all of these uses without errors due
>> to switched include ordering or omissions or whatever.
>>
> Actually, while recently re-reading some of the "aggressive" changes
> of last, I have come to realize the same thing.  Since the removal
> of INCLUDES is only implemented in master, I saw no hurry in
> reverting it though; but reconsidering it was on the radar.  Bottom
> line: a patch in that direction would be welcome, especially if its
> commit message condenses the rationales you have given here.

Oh, that's a relief! Sorry for slamming down open doors...

>> Also, this quote from commit message removing INCLUDES support:
>>
>>      "So, by removing it in Automake 1.14, we will simplify
>>      the transition path for people that want to switch to
>>      Automake-NG."
>>
>> is just brain-damage and completely ass-backwards, if you ask me.
>> Damnit, if there is a goal to make it easy to switch, that should
>> be the sole responsibility of Automake-NG. Especially for trivial
>> stuff like this. Period.
>>
> I'm not happy to say this, but I must admit I agree with you now.
> 
> This wrong approach is probably the result of me trying to keep a foot
> in both camps -- that is, maintaining mainline Automake while trying
> to encourage a switch to Automake-NG in the long term.  Probably not a
> good move, for any of those projects.
> 
> I should at this point decide whether just devote my "Automake time"
> to mainline Automake (which amounts at letting Automake-NG die,
> basically) or to Automake-NG (after tying some loose ends in the
> mainline Automake code base, of course).

My intention was not to scare you away from either of the
projects!

And in fact, I just expressed how I think removing support for
INCLUDES is wrong, for *both* projects! There's no sitting on
two chairs here. It's just not the sort of change your users
ask for, and it should not have been made. It's perhaps the sort
of change you sometimes wish you can do as a maintainer, but
that doesn't mean it's a good idea to do it. It will only cause
churn, ripples and bugs for your users. It can be a good
idea to remove support for long deprecated stuff when it hinders
progress, but supporting INCLUDES will never hinder progress (I
fail to see how anyway). To me, the change was made just because
it was perceived as messy or redundant. But the messiest part
of the removed code was the deprecation warning. Carrying on
with the support for INCLUDES in automake costs nearly nothing.
Supporting INCLUDES in automake-NG costs nearly nothing. The
gain is obvious; why would you *ever* want to hinder (or kill)
the upgrade path deliberately?

I think there are two classes of deprecations. One happens only
in the manual, when a better interface is invented, but the
support for the old interface is trivial to keep. There is
seldom a reason to kill the support for the old interface in
this case. Also, you don't need to pester users with deprecation
warnings as you are not intending to remove the support anyway
(that's what MS does when they want to lure their customers
deeper into the lock-in. Deprecating fopen et.al., like they
are going to remove it? Yeah, right. Sheesh...). If you still
want a warning for this case it should definitely be off by
default. The other class is when there is some fundamental
technical problem with keeping support for the old interface,
and you actually intend to remove it somewhere down the line.
In this case, your users are going to need to switch interfaces,
and they better do it sooner rather than later. For their own
good. This is where a deprecation warning that is on by default
is useful.

All in my humble opinion, of source. Errm, of course.

Cheers,
Peter

PS. Keep up the good work. I apologize for being too blunt.