Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS

[Stefano Lattarini]

[+cc automake-ng]

On 02/01/2013 09:45 AM, Peter Rosin wrote:
> Hi!
> 
> 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.

> [SNIP] good rationales

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

So, is anyone using or playing with Automake-NG, or at least
contemplating the idea to do so in the short term?  Or should
we just let the project die?

> [SNIP]

Regards,
  Stefano

Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS

[Russ Allbery]

Stefano Lattarini  writes:

> So, is anyone using or playing with Automake-NG, or at least
> contemplating the idea to do so in the short term?  Or should we just
> let the project die?

I'm not personally using it or playing with it yet, but I like the idea of
rethinking the project and eliminating historic cruft and old workarounds.
I also agree with assuming GNU make; I think it's now hard to find a
system that doesn't have GNU make, and it seems likely it will, in the
long run, allow you to generate much more efficient build systems.  Also,
you seemed to be having fun with it, and I think that's important!

To be honest, the main reason why I've not already started playing with it
is that it's not packaged for Debian, which is enough of a hurdle that I
haven't found the time to fiddle with it.

-- 
Russ Allbery (r...@stanford.edu) 

Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS

[Bob Friesenhahn]

On Fri, 1 Feb 2013, Stefano Lattarini wrote:


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

So, is anyone using or playing with Automake-NG, or at least
contemplating the idea to do so in the short term?  Or should
we just let the project die?


While I understand that your time is limited, the logic of this last 
paragraph escapes me.  Automake has benefited significantly from your 
work in the past couple of years.  Other than pain/complaints caused 
by the sudden removal of long-deprecated (but not verbosely warned) 
features, Automake has been working better than before.  I don't see 
why Automake-NG should suffer or be aborted because of some complaint 
about Automake.  If Automake can be put back on a stable course, then 
you should be able to re-focus on Automake-NG.


None of us will be encouraged to experiment with or depend on 
Automake-NG by such questions.  If Automake-NG is heading to the fate 
of the Quagmire, then all of us should fear to use it.  However, if it 
does not doom us to the fate of the Quagmire and is believed to have a 
future with official releases, then we can start to depend on it and 
take pride in using it.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS

[Stefano Lattarini]

On 02/01/2013 07:18 PM, Bob Friesenhahn wrote:
> On Fri, 1 Feb 2013, Stefano Lattarini wrote:
>>
>> 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).
>>
>> So, is anyone using or playing with Automake-NG, or at least
>> contemplating the idea to do so in the short term?  Or should
>> we just let the project die?
> 
> While I understand that your time is limited, the logic of this last
> paragraph escapes me.  Automake has benefited significantly from your
> work in the past couple of years.
>
Still, when I (mostly unwittingly) had let my interest in Automake-NG steer
decisions for mainline Automake, the results have not been good .  I now
realize that trying to advance the development of both mainline Automake
and Automake-NG puts me in a "conflict of interest" situation, which makes
me susceptible of making choices suboptimal for one of the projects while
I'm focusing on the other.  That is not good.  That's why I think I need
to choose only one of these projects to actively devote myself to, and do
only basic "maintenance work" on the other [1].

 [1] For Automake-NG, this maintenance work would mean keeping the master
 branch regularly merged in ng/master, and ensure the testsuite keeps
 passing.

> Other than pain/complaints caused by the sudden removal of
> long-deprecated (but not verbosely warned) features,
> Automake has been working better than before.  I don't see why
> Automake-NG should suffer or be aborted because of some complaint
> about Automake.
>
Because I fear I won't be able to focus on both at the same time,
without risking to favor one at the detriment of the other.

> If Automake can be put back on a stable course,
>
I think it easily can, at this point.  IMHO, the new pending features and
deprecations are all worthwhile; it's just some overly-eager removal of
old features that should be reverted.

> then you should be able to re-focus on Automake-NG.
>
That would mean limiting myself to basic maintenance work on mainline
Automake.  Which can be a worthwhile trade-off, but only if I can have
some hope that someone is going to actually use or at least play with
Automake-NG

> None of us will be encouraged to experiment with or depend on Automake-NG
> by such questions.
>
The fact that I've dissuaded you to possibly depend on it is a good thing :-)
I wouldn't trust it to such degree yet.  But starting to experiment with it
would give precious real-world feedback, and that is of paramount importance
if we want to reduce the risk of painting us in a corner (design-wise, or
compatibility-wise, or in other unanticipated ways).

> If Automake-NG is heading to the fate of the Quagmire, then all of us
> should fear to use it.
>
I fear that what killed Quagmire (developed by Tom Tromey, so not some
random unexperienced guy) was precisely the lack of early adopters and
experimenters.  Lacking users, you lack feedback, you lose motivation,
and the project dies.

> However, if it does not doom us to the fate of the Quagmire and is
> believed to have a future with official releases, then we can start
> to depend on it and take pride in using it.
>
A first step would certainly be making it a separate project on
Savannah, rather than just a glorified branch in the Automake Git
repository (plus a dedicated mailing list).  Anyone has experience
or suggestions on how to better proceed in this direction?

Thanks,
  Stefano

Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS

[Stefano Lattarini]

Hi Russ, thanks for the feedback.

On 02/01/2013 07:38 PM, Russ Allbery wrote:
> Stefano Lattarini  writes:
> 
>> So, is anyone using or playing with Automake-NG, or at least
>> contemplating the idea to do so in the short term?  Or should we just
>> let the project die?
> 
> I'm not personally using it or playing with it yet, but I like the idea of
> rethinking the project and eliminating historic cruft and old workarounds.
> I also agree with assuming GNU make; I think it's now hard to find a
> system that doesn't have GNU make, and it seems likely it will, in the
> long run, allow you to generate much more efficient build systems.  Also,
> you seemed to be having fun with it, and I think that's important!
>
I'm happy to read this :-)

> To be honest, the main reason why I've not already started playing with it
> is that it's not packaged for Debian, which is enough of a hurdle that I
> haven't found the time to fiddle with it.
> 
Debian's attitude is perfectly understandable here, since the package is
still at an alpha status, and hasn't seen any release or pre-release yet.

Which makes me think that forcing users to bootstrap the project from a
Git branch hidden in Automake's repository in order to use it might be
hampering their willingness to give it a try.  It's probably time to
separate for good Automake-NG from mainline Automake, and to issue some
early alpha releases.  Not sure when I'll have time to do this properly
though ...

Thanks,
  Stefano

Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS

[Bob Friesenhahn]

On Fri, 1 Feb 2013, Stefano Lattarini wrote:



I'm happy to read this :-)


You should be happy that a number of us have been interested in 
Automake-NG enough to remain subscribed to its mailing list and 
provide comments on directions and ideas.  Being on the mailing list 
requires a level of dedication.



Debian's attitude is perfectly understandable here, since the package is
still at an alpha status, and hasn't seen any release or pre-release yet.

Which makes me think that forcing users to bootstrap the project from a
Git branch hidden in Automake's repository in order to use it might be
hampering their willingness to give it a try.  It's probably time to
separate for good Automake-NG from mainline Automake, and to issue some
early alpha releases.  Not sure when I'll have time to do this properly
though ...


Git surely makes it easy to promote a branch to a new top-level 
repository.  Having it available by default in a repository would be 
easier to grasp for git-challenged people like me.  Alpha/beta release 
packages would help quite a lot.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS

[Thien-Thi Nguyen]

() Stefano Lattarini 
() Fri, 01 Feb 2013 19:59:58 +0100

   A first step would certainly be making it a separate project on
   Savannah, rather than just a glorified branch in the Automake Git
   repository (plus a dedicated mailing list).  Anyone has experience
   or suggestions on how to better proceed in this direction?

No no, that will only let things drift apart more quickly.  While
everything is still in one head (yours), it should be in one repo, IMHO.

Perhaps you should post a "help wanted" notice, select a worthy hacker
for Automake (presuming you want to focus on Automake-NG) from the
throng of candidates (one hopes), and then, after a suitable ramp-up
period, let the new maintainer decide the fate of the code.

[cc -> to, trimmed]

-- 
Thien-Thi Nguyen . GPG key: 4C807502
.  NB: ttn at glug dot org is not me   .
. (and has not been since 2007 or so)  .
.ACCEPT NO SUBSTITUTES .
... please send technical questions to mailing lists ...


pgpybmRgpUTIe.pgp
Description: PGP signature

Re: [Automake-NG] 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.

Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS

[Eric Blake]

On 02/01/2013 05:00 PM, Peter Rosin wrote:
> 
> And in fact, I just expressed how I think removing support for
> INCLUDES is wrong, for *both* projects!

I agree that removing it from automake is counterproductive.  But I
support removing it from Automake-NG - as long as we are moving to a
newer environment, we can afford to modernize and get rid of namespace
pollution.

> but supporting INCLUDES will never hinder progress (I
> fail to see how anyway).

Namespace cleanliness in Automake-NG is a nice goal, one where it is
worth warning about (but not removing) use of INCLUDES in Automake in
order to make it easier to switch to Automake-NG.  It may turn out that
in Automake-NG, supporting INCLUDES costs a lot more clutter than
desirable.  Remember, in Automake-NG, we use GNU make features, such as
the ability to easily iterate over all targets that match a certain glob
pattern - but this only works if a pattern is easy to write.  It is easy
to glob for all things beginning with AM_, but harder if you have to
special-case for outliers like INCLUDES.

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

I agree that _in automake_, carrying support for INCLUDES costs almost
nothing, since we already have code to detect INCLUDES, and since we
already have to issue warnings about using INCLUDES.

> Supporting INCLUDES in automake-NG costs nearly nothing.

This, however, is a statement I'm not willing to concede; so while I
agree with the decision to deprecate (but not remove) INCLUDES from
automake, I think it is fair game to state that someone switching to
Automake-NG should be prepared to avoid INCLUDES, as part of that switch.

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

Same goes for me :)

> 
> Cheers,
> Peter
> 
> PS. Keep up the good work.

Likewise, I applaud your efforts on both automake and Automake-NG, and
hope that we can get automake stable enough that you can spend some fun
time with Automake-NG.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS

[Peter Rosin]

On 2013-02-02 01:15, Eric Blake wrote:
> On 02/01/2013 05:00 PM, Peter Rosin wrote:
>> Supporting INCLUDES in automake-NG costs nearly nothing.
> 
> This, however, is a statement I'm not willing to concede; so while I
> agree with the decision to deprecate (but not remove) INCLUDES from
> automake, I think it is fair game to state that someone switching to
> Automake-NG should be prepared to avoid INCLUDES, as part of that switch.

Oh. I claim ignorance. I blindly assumed the implementation in -NG
was just as trivial as in plain old Automake. When there are technical
reasons to drop INCLUDES in Automake-NG, it's a totally different
situation. I then agree that it's perfectly ok to issue a (default
visible) deprecation warning in Automake, in order to enable an easy
upgrade path to -NG in the future.

I should have known that the removal wasn't as trivially stupid as
it looked at first sight...

Cheers,
Peter

Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS

[Akim Demaille]

Le 1 févr. 2013 à 10:35, Stefano Lattarini  a 
écrit :

> So, is anyone using or playing with Automake-NG, or at least
> contemplating the idea to do so in the short term?  Or should
> we just let the project die?

I subscribe to all the good opinions about NG that have been
made here.  I would definitely use it once there is a release
(I have already been criticized several times for having used
then-CVS versions of the Autotools in Bison, and I don't want
to go in that direction again).  Actually I am eagerly waiting
for a release, I really want to be able to rely (cleanly) on
GNU Make.

I wouldn't split the repository either.