Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > On Sat, 14 Jan 2006, Russ Allbery wrote:
>> The problem is, in a nutshell, this doesn't actually work reliably. If > It does inside Debian (you can explicitly choose a given version, and > upgrade to the next only after some testing). It *mostly* does among > minor versions of the autotools, if whomever wrote the scripts didn't > abuse internals or fork-and-modify macros. Unfortunately, it's rather tricky to do this properly. I've done the autotools cleanup of a lot of different projects, and I think I can safely say that almost no one knows how to write safe autotools scripts. I agree with your point about Automake and libtool; it's a lot easier to handle it in Debian because you can depend on the specific version. I worry more about Autoconf, which does sometimes break things from version to version. Of course, at this point, Autoconf upstream is somewhat on life support, so maybe it doesn't matter as much any more. > Now, that's a valid complain. But it is a reason to use something ELSE > than autotools, and not to keep around old broken stuff inside Debian > packages. Believe me, I'd be happy to use something that's a little saner to work with for the packages I'm also upstream for. I already refuse to use Automake for various reasons. I've just never found anything else that's really a reasonable replacement for Autoconf or libtool (and Autoconf does do a good job if one really knows how to write macros, although it's harder than it should be to express a lot of things in its language). > But I haven't seen great changes since automake 1.6, nor since autoconf > 2.52. They now warn you of breakage the previous versions didn't > complain about, but that's something gcc 4 does as well, for example. > Maybe I am just lukcy? I don't remember the last thing I got bitten by, but I think it was more recent than 2.52. Something related to LIBOBJ, maybe? > Well, it depends. I *rewrote* the autotools scripts for substantial > packages to clean up the usual load of crap people put in there, because > I know well that it won't stand up for abuse (crap and dumb hacks are > something that lacks good resilience, as we all know :P). This speaks > against the quality of the autotools documentation and its learning > curve. Yup. The other problem is that this sort of fix is often very hard to get accepted upstream, since it tends to be a substantial change that partly looks cosmetic and the build tools all work for them on their platforms. It's also often quite a bit of work to turn the broken macros people use into something clean. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]