Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
That assumes you *can* build from the distributed tarball without regenerating the autoconf machinery with a locally patched autoconf. Which is not always true.
Security implications for user interface changes!
Posted Dec 18, 2012 14:08 UTC (Tue) by mirabilos (subscriber, #84359)
I guess I could build the current version of GNU m4 with autoconf 2.62 once locally, then use that to port autoconf 2.69, then take the then-current GNU m4 distfile from the FSF, extract it, regenerate all the machinery with what we need and then publish my own GNU m4 distfile that can be used to solve this cycle. Meh.
It’s probably even doable since our own machinery for ports etc. doesn’t change any more, it’s pretty stable.
Or, of course, get the required changed into autotools and libtool. But that has been like wading through treacle and got worse when dfjoerg got involved. Plus, we do require a unique set of changes for libtool 1.5 (working with autoconf 2.13 and 2.5x/2.6x) and possibly libtool 2.x, since we do need to regenerate older softwares. (Right now, the amount of libtool 2.x using software can be counted on one hand, and we just patched it to use our patched 1.x instead of trying to grasp the 2.x series.)
Posted Dec 18, 2012 18:00 UTC (Tue) by nix (subscriber, #2304)
Bootstrap loops are not even slightly unusual. Why you consider it so much worse for GNU autoconf and m4 (which is meant for execution by developers and packagers) than for, say, GCC (which is needed by everyone building software and is far, far more complex) is somewhat unclear.
Posted Dec 18, 2012 18:12 UTC (Tue) by mirabilos (subscriber, #84359)
That assumes it’s fine to use binaries.
Which is not. That’s the whole point of BSD ports.
Besides, it doesn’t scale. You’d need “a single binary” times amount of OSes, versions (and possibly, in-between snapshots with differing libc versions, libm versions, etc.), and architectures supported. That’s a *lot*. Plus you’d need access to machines to build them all. I do not have access to, say, an OSX 10.3 machine any more, since it got upgraded, but somewhere out there, someone might still use it. And my Interix machine had hardware issues and went to the trash, and the only other Win2k machine I have already has Cygwin on it, which conflicts.
So, it does not work period.
Posted Dec 18, 2012 20:14 UTC (Tue) by nix (subscriber, #2304)
If your model depends on generating configure on every build platform, your model is *broken*. That's not how configure is meant to work. Generate once -- run everywhere.
Posted Dec 18, 2012 20:38 UTC (Tue) by mirabilos (subscriber, #84359)
In fact, all target platforms (Interix to the lowest degree)
are a complete working, usually self-hosted, Unix system.
They just do not include GNU m4. Or GNU make, for that matter
(well, Mac OSX does, but let’s ignore that piece).
That model is *not* broken, and has worked with GNU tools for
several years, but apparently, recently, the GNU vendor lock-in
(something I’d normally expect from commercial/proprietary Unix
makers) got worse. (Not yet at the level of Poettering, but close.)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds