Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS
On Fri, Feb 1, 2013 at 4:35 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: 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? IMO, you should revisit your initial decision to have Automake-NG instead of Automake-2.0, the latter of which would make having a foot in both pools far more natural. Your requirements change in several ways, including how to handle the upgrade path between the two. You could also just blanketly deprecate everything non-gnu in automake-2.0. Because honestly... if you proceed with Automake-NG, will there ever be a mainline 2.0? Or will it just eventually die anyway?
Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS
Hi Akim. On 02/02/2013 08:24 AM, Akim Demaille wrote: Le 1 févr. 2013 à 10:35, Stefano Lattarini stefano.lattar...@gmail.com 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). Oh, but I wasn't suggesting to use Automake-NG to bootstrap an official GNU package! Having any such package depending on an alpha-quality software sounds indeed very wrong. What I meant was that it would be nice to have an experimental branch in the official repositories of some GNU packages, where interested maintainers can experiment at using Automake-NG; that would already provide invaluable real-world feedback. Actually I am eagerly waiting for a release, I really want to be able to rely (cleanly) on GNU Make. That would be an alpha release though; we can aim at a series of 0.x releases (making it clear that backward-compatibility won't be guaranteed in any way until the 1.0 release), but I'd start doing that only after the current code base has seen some more exposure to the real world. I wouldn't split the repository either. OK, I'm fine with that. Less work to do :-) Thanks, Stefano
Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS
On 02/01/2013 08:27 PM, Bob Friesenhahn wrote: On Fri, 1 Feb 2013, Stefano Lattarini wrote: [SNIP] 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. Other people have spoken against the need of such a split though. However ... Alpha/beta release packages would help quite a lot. ... everyone has spoken in favor of this, so this is where we should head eventually (not very fast, because the loose ends and pending changes in Automake should be dealt with first, and doing that properly might easily require few months). Thanks, Stefano
Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS
Hi Peter, Eric, thanks for the feedback and the support. On 02/02/2013 01:51 AM, Peter Rosin wrote: 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. For now indeed it is, but it might be nice to keep the door open to future refactorings or even sweeping changes to the implementation (which has been done heavily for other parts of the codebase, see for example Texinfo support). Since you are going to need an audit of your whole build system anyway if you are planning to switch to Automake-NG, having to get rid of $(INCLUDES) in the process doesn't add any real burden; OTOH, as you noted, doing so when merely switching to a new major Automake version might be a real hassle, since in that case the backward incompatibilities should be definitely fewer and much smaller, and shouldn't force you to revisit your whole build system. And actually, even that wouldn't be a problem if there were only few usages of $(INCLUDES) left in the wild, but as you noted, it has been actively deprecated for a too short time, so that most developers might not even be aware yet of its deprecation. 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... Well, it wasn't for Automake-NG, but it has turned out it mostly is for mainline Automake. Regards, Stefano
Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS
On 02/02/2013 01:40 AM, Stefano Lattarini wrote: 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). Oh, but I wasn't suggesting to use Automake-NG to bootstrap an official GNU package! Why not? The end product tarball will require GNU make, but other than that, the end user won't care whether automake or Automake-NG was used to create the tarball. Besides, it is already possible to use automake in a manner that requires GNU make, so end users of those packages won't notice a difference. I guess where it might matter is if distros try to rerun Automake-NG as aggressively as they try to rerun automake on existing packages. Existing distros have stacked the autotools so that they can rerun the same version of automake as a package was originally built with, even if a newer automake has been released since then. So if Automake-NG releases are breaking backwards compatibility for the first little while due to being at alpha quality, that implies that distros will have to repeat their efforts on providing a stacked Automake-NG release for any cases where a package needs to be re-autotooled as part of the distro process. On the other hand, most of the cases where distros end up relying on stacked automake is for packages that aren't actively maintained upstream, and therefore need to have their configure.ac and Makefile.am patched downstream. It can be assumed that the early adopters of Automake-NG are still active, and will be released frequently enough, that it will be easier to fix issues upstream and re-release than to make the distros have to carry downstream patches against configure.ac and Makefile.am that require rerunning the autotools as part of the distro process. -- 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
On Sat, 2 Feb 2013, Stefano Lattarini wrote: 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. Other people have spoken against the need of such a split though. However ... Doesn't Git make it as easy to diff and merge between repositories as easily it does between branches in the same repository? The source control tool named after a fluid metal does. 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
[+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
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
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
Hi Russ, thanks for the feedback. On 02/01/2013 07:38 PM, Russ Allbery wrote: Stefano Lattarini stefano.lattar...@gmail.com 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
() Stefano Lattarini stefano.lattar...@gmail.com () 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
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
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
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
Le 1 févr. 2013 à 10:35, Stefano Lattarini stefano.lattar...@gmail.com 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.
