Rejuvenating Autoconf
Rejuvenating Autoconf
Posted Oct 24, 2020 10:20 UTC (Sat) by atnot (subscriber, #124910)Parent article: Rejuvenating Autoconf
Thank you for doing this work.
Posted Oct 24, 2020 13:10 UTC (Sat)
by david.a.wheeler (subscriber, #72896)
[Link]
If you ever want to use the autotools, I made a short set of videos that may be helpful:
Posted Oct 24, 2020 18:46 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (34 responses)
No thanks for palliative care of a project that has cost gazillions of developers a lot of their time and some of their sanity and largely contributed to all build systems being "universally despised"[a]. The sooner autotools die and the sooner people get back some time to advance the state of the art and maybe even like build systems again.
1. As detailed in other comments (and in the article itself!) the problems solved by autotools have mostly disappeared. If you still need to compile something on AIX or Solaris then get the companies you're paying (!) for these to fix the actual compatibility problems instead[b]. They now have to fix these anyway for all the projects that don't use autotools anymore. There is still some disastrous and extremely costly lack of standardization across libraries and toolchain interfaces[c] affecting even newer build systems and anything that helps maintain this status quo is actually harmful. Let's please focus and ask developers to spend their very limited build patience and energy on tomorrow's build problems, not yesterday's.
2. While no alternative to autotools is so good that developers will start "loving" build systems yet (is that ever possible?), there are _multiple_ alternatives which are _all_ massively more pleasant and many are way past the "production-grade" phase. They deserve time and effort much more than autotools do.
If some people want to maintain autotools then great... for them! Sorry but no: it is_not_ great for the rest of us because it is holding us back for a little longer before the inevitable.
[a] https://mesonbuild.com/Design-rationale.html
PS: I'm linking to meson because it has the best "Design rationale" page, I'mnot claiming it's the "best" tool (but I find it pretty good)
Posted Oct 24, 2020 20:35 UTC (Sat)
by pizza (subscriber, #46)
[Link] (1 responses)
Sure, one can argue about the details of autotools' implementation and question whatever arbitrary cutoff it has (or doesn't have) for "ancient" systems... but please keep in mind that while the exact details will change, tomorrow's build problems will be remarkably similar to yesterday's -- software (and deployment) environments are rarely homogenous and usually bleed outside the vertical tooling/language monocultures that are in vogue these days.
Emphasis on bleed.
Posted Oct 24, 2020 21:54 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
These days people need dependency management, reproducibility, cryptographic checksums for dependencies, bill of materials support, massively parallel builds, etc. None of this was even on the radar back in 90-s.
Posted Oct 25, 2020 10:21 UTC (Sun)
by nix (subscriber, #2304)
[Link] (22 responses)
Autoconf is in widespread, active use still. Things in widespread, active use need maintenance as the world around them changes. Autoconf hasn't had it of late: it's really good it's seeing some.
I think maybe I should pick a few projects and make sure they work with 2.60 :)
Posted Oct 25, 2020 22:30 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (12 responses)
> just upgrading autoconf versions is a very big job for GCC, let alone switching build systems
Perhaps GCC should just spend a couple of weeks migrating to something sane instead of continuing to try and eat the cactus? And yes, it's going to take about 2-3 weeks of work.
> Autoconf is in widespread, active use still. Things in widespread, active use need maintenance as the world around them changes. Autoconf hasn't had it of late: it's really good it's seeing some.
Posted Oct 25, 2020 22:33 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Oct 26, 2020 15:39 UTC (Mon)
by nix (subscriber, #2304)
[Link] (10 responses)
(And CMake is probably impossible to use as a replacement: last I checked its cross-compilation support was terrible. Meson might be usable, in time, but even there the problem is that it depends on Python 3, and that's a long way down the dependency stack for a foundational toolchain component like the C compiler.)
Posted Oct 26, 2020 16:33 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
Posted Oct 26, 2020 17:09 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
The bootstrap stage can be removed entirely, it serves no real purpose these days. But leaving it is not a big deal, you'll just need staged CMake files for this (at least that's how I would do it).
The rest of normal GCC is just a C++ program, nothing really special (sure, a lot of care needs to be taken to handle all the build options).
And the final part is the test suite. I have far less experience there.
> And CMake is probably impossible to use as a replacement: last I checked its cross-compilation support was terrible.
Posted Oct 27, 2020 14:06 UTC (Tue)
by peter-b (guest, #66996)
[Link] (6 responses)
As an escapee from compiler development, I can absolutely assure you that compiler bootstrapping is still not merely important but essential.
Posted Oct 27, 2020 14:57 UTC (Tue)
by smurf (subscriber, #17840)
[Link]
The latter is proper bootstrapping. You need (or needed) it to build a Rust compiler that's written in C, before you can switch to the "real" Rust compiler written in Rust. (s/Rust/Golang/ if you want to. Or whatever.)
The former is not.
As there's no realistic scenario where you'd want to build GCC with a non-GCC compiler (Clang understands GCC's C extensions, thus it doesn't count) GCC's bootstrapping infrastructure is superfluous. Yes you need to keep some bits&pieces of it for cross-compiling to another architecture – but that's cross-compiling, not bootstrapping.
Posted Oct 27, 2020 15:23 UTC (Tue)
by FraserJGordon (subscriber, #96690)
[Link]
Posted Oct 27, 2020 18:20 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
GCC is not a particularly involved code, so it can just be written to run on something reasonable (modern-ish Clang, gcc, MSVC). With cross-compilation support this will be enough for anything realistic.
Posted Nov 20, 2020 21:51 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Posted Oct 28, 2020 3:13 UTC (Wed)
by pabs (subscriber, #43278)
[Link] (1 responses)
Posted Oct 28, 2020 3:24 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
And it doesn't even apply here, the "boostrap" stage in GCC still requires a compiler, it just has very low requirements for it.
Posted Oct 30, 2020 21:52 UTC (Fri)
by jonesmz (subscriber, #130234)
[Link]
Posted Oct 26, 2020 4:34 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (8 responses)
The name is "sunk cost fallacy"
Posted Oct 26, 2020 6:03 UTC (Mon)
by jem (subscriber, #24231)
[Link] (1 responses)
Now, if a *new* project is started using Autoconf then that would be another matter.
Posted Oct 26, 2020 7:33 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
No.
Posted Oct 26, 2020 15:42 UTC (Mon)
by nix (subscriber, #2304)
[Link] (5 responses)
It seems entirely reasonable to me to look at that massive pile of work, not one bit of which would benefit your users and some of which might well harm them, and say "hell no".
Posted Oct 26, 2020 17:40 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (4 responses)
I just spend time double and triple checking my comment. While I clearly warned it would lack nuance, I didn't write anything remotely close to this.
Some good stuff in the rest of your comment but when the first line is deliberately and totally making up what the other said then the discussion can only go nowhere fast. This is much worse than not making an effort to understand each other. I've noticed "deliberate straw man" has unfortunately become the most common "discussion" style nowadays, role-modelled from the most obscure forums all the way up to the highest level of politics but I'm still refusing to "adapt" to this. Looks like we both have something old we like to cling to :-)
Posted Nov 1, 2020 2:07 UTC (Sun)
by jschrod (subscriber, #1646)
[Link] (3 responses)
Pot, meet kettle.
Posted Nov 2, 2020 9:02 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (2 responses)
Posted Nov 2, 2020 10:08 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
The sunk cost fallacy is when you choose not to switch to a cheaper option, because of what you've spend on the more expensive option. It seems quite clear here that for many people, the cost of switching is very high, because they will have to (in one form or another) - reimplement a lot of autoconf. This makes maintaining autoconf the cheapest option!
Cheers,
Posted Nov 2, 2020 17:01 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
> The sunk cost fallacy is when you choose not to switch to a cheaper option, because of what you've spend on the more expensive option.
The sunk cost fallacy is subconsciously give value to something that has none anymore and let that influence you. Influence is not always enough to win an (often collective) decision.
Sunk costs are much complicated in software than in say finance because _knowledge_ of an existing system is valuable: it makes knowledgeable workers much more productive which is of course very valuable, especially from the perspective of the experts. But what about the value for the project as a whole? The value of newer build systems is of a completely different sort: they require less expert knowledge and many more people can and do help with their maintenance. Interestingly, this decreases the "market" value of the old experts.
> It seems quite clear here that for many people, the cost of switching is very high, because they will have to (in one form or another) - reimplement a lot of autoconf. This makes maintaining autoconf the cheapest option!
It's pretty obvious that the minute after flipping the switch away from autoconf, a project that just migrated has spent a lot and gained nothing yet. I don't think anyone questioned that. Every technological choice is a large investment and its value must be studied _over time_.
Posted Oct 25, 2020 17:03 UTC (Sun)
by jnxx (guest, #142729)
[Link] (3 responses)
There is a lot of interest from people who want cross-platform builds, probably for
I understand that it would be nice for some developers if everything there worked
Kudos to the people which put work into such an important, hard, and sometimes thankless project.
Posted Oct 25, 2020 17:48 UTC (Sun)
by martin.langhoff (guest, #61417)
[Link] (1 responses)
Fair enough, but remember WSL is here now, and for most uses, it's more than good enough.
See https://docs.microsoft.com/en-us/windows/wsl/install-win10
Posted Oct 26, 2020 17:30 UTC (Mon)
by perennialmind (guest, #45817)
[Link]
I should like WSL more than I do. WSL1 especially shrinks the gap between the worlds so that one may casually step from one to the other. Pipes, fifos, signals, etc all cross the gap. Microsoft produced a figurative automobile, but I still want a faster horse. I want MSYS2 and Cygwin, with fewer compromises.
That's why I'm hoping that Microsoft's transfer of affection to WSL2 gives the midipix project some breathing room. From the Win32 point of view, it's just one more libc among many, sitting atop
Posted Oct 26, 2020 10:57 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
> CMake is a major mess with more or less unusable documentation.
I know pre-3.0 docs were quite terrible (single page monstrosity, etc.), but we now use Sphinx for everything. A contributor even went through recently and added `since` tags for the main APIs (module APIs still lack them I think). We do still lack "story" and guide-like documentation (alas, time and $$), but Craig Scott's book is supposed to be really good.
https://cmake.org/cmake/help/latest/
I agree about the "mess" (though likely differ in degree :) ), but build systems for C and C++ that support more than the bare minimum set of compilers and platforms are just inherently going to be that way because the ecosystem is just such a mess to begin with.
Posted Nov 2, 2020 1:34 UTC (Mon)
by ringerc (subscriber, #3071)
[Link] (1 responses)
The simple ones are beautiful until you step outside their design boundaries and want to do something they consider inappropriate. Like link to code that wasn't in turn built with the same build system or shipped with some kind of build system manifest file. Oh, the library maintainer should just ship a libfoo.whizzmagic !
The ones that don't try to pretend the world is simple and can be re-made afresh in their own vision tend to become mires of complexity, multiple outdated ways of doing things, stale documentation, and confusion.
Then some, like CMake, seem to manage to find the worst of both worlds, and still be pretty useful.
Posted Nov 2, 2020 3:13 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
Posted Nov 3, 2020 18:21 UTC (Tue)
by anton (subscriber, #25547)
[Link] (2 responses)
I notice in many places, including your posting and the Meson design rationale a disdain for maintaining compatibility with old stuff. If everybody followed this principle, the software you use now would soon stop working; ok, so you get the new version (if there is one), but that would of course work differently than you are used to, so you have to change everything that you built that relies on it.
Interestingly, the first look at the Meson design rationale page gave the right impression; I had to adjust fonts and colours before I found it visually readable. Usually such pages are not worth reading, and that page was no exception.
Posted Nov 3, 2020 20:09 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (1 responses)
I don't see any disdain at https://mesonbuild.com/Design-rationale.html#5-must-not-a... , just a trade-off because meson is not a well-funded, commercial project. Any other reference?
I love old stuff when bugs can be fixed cleanly where they are. My disdain is only for ugly workarounds - typically required by commercial and/or closed-source systems - unmaintenable wrapper and too many layers of indirection.
> Interestingly, the first look at the Meson design rationale page gave the right impression; I had to adjust fonts and colours before I found it visually readable. Usually such pages are not worth reading, and that page was no exception.
There seems to be fair number of projects who found meson documentation readable enough: https://news.ycombinator.com/item?id=24881897
The meson project is minimally "staffed" (which goes back to my initial comment) and last time I checked it was unsurprisingly not overstaffed with talented documentation experts. However it is very friendly to "drive-by" contributions so I bet they'll be delighted to accept fixes for your unusual browser configuration.
PS: I've met a surprising number of long-time open source hackers (even some famous ones) who have never used the "info" command. FWIW I do use it all the time.
Posted Nov 4, 2020 11:53 UTC (Wed)
by anton (subscriber, #25547)
[Link]
Considering Ubuntu 12.04 (the then-current LTS release) obsolete in December 2012 is a pretty strong sign of disdain for maintaining compatibility with old stuff, actually even with then-current stuff.
My "unusual browser configuration" is to heed the web page's requests for fonts and colours. The Meson developers invested a bit of their "minimal" staffing to ask for a tiny font and for light-gray-on-dark-gray colours. After working around that, the content is readable, but not worth reading.
Posted Oct 24, 2020 20:29 UTC (Sat)
by ballombe (subscriber, #9523)
[Link]
So an announcement of a new autoconf version after all this time of stability is a cause of dread for a lot of users, unfortunately, even if it is probably not justified in this case.
Sometime a software being frozen can be a blessing.
Rejuvenating Autoconf
https://m.youtube.com/watch?v=4q_inV9M_us
Rejuvenating Autoconf
[b] https://mesonbuild.com/Design-rationale.html#5-must-not-a...
[c] https://github.com/zephyrproject-rtos/zephyr/issues/16031 toolchain abstraction
Rejuvenating Autoconf
Rejuvenating Autoconf
Rejuvenating Autoconf
The sooner autotools die
And all the programs that are using them... what? Die along with them? Invest enormous amounts of time migrating to a new build system? (For things that rely on things like cross-compilation working, a truly enormous amount of time: just upgrading autoconf versions is a very big job for GCC, let alone switching build systems).
Rejuvenating Autoconf
GCC is an example of how NOT to do things. Clang+LLVM is of comparable complexity, yet its build system is stupidly easy to follow and understand:
https://github.com/llvm-mirror/clang/blob/master/CMakeLis... and https://github.com/llvm/llvm-project/blob/master/llvm/CMa... (yes, there are some helper files, but the bulk of functionality is in these two files).
Sometimes maintenance should mean just killing it.
Rejuvenating Autoconf
Rejuvenating Autoconf
Rejuvenating Autoconf
Rejuvenating Autoconf
Check it again.
Rejuvenating Autoconf
Rejuvenating Autoconf
Rejuvenating Autoconf
Rejuvenating Autoconf
Rejuvenating Autoconf
Rejuvenating Autoconf
Rejuvenating Autoconf
Rejuvenating Autoconf
Rejuvenating Autoconf
Rejuvenating Autoconf
Rejuvenating Autoconf
Rejuvenating Autoconf
Rejuvenating Autoconf
Rejuvenating Autoconf
Rejuvenating Autoconf
Rejuvenating Autoconf
Wol
Rejuvenating Autoconf
Rejuvenating Autoconf
> https://mesonbuild.com/Design-rationale.html
using GNU Linux/FLOSS software on Windows. Clearly, more people
want to use free software libraries and tools on Windows.
neatly on Windows. But it can't be the fix to Window's historical lack of
compatibility to break important tools and infrastructure for Linux.
And I have worked a bit with CMake, Conan and such.... where autotools and Make
are a bit crufty but work, CMake is a major mess with more or less
unusable documentation. This is not going to save anyone using Linux work.
Rejuvenating Autoconf
> using GNU Linux/FLOSS software on Windows. Clearly, more people
> want to use free software libraries and tools on Windows.
Rejuvenating Autoconf
NTDLL.DLL. To the libraries I enjoy on my linux distro, it's just another POSIX build target using the musl libc. And you can mix and match.
Rejuvenating Autoconf
Rejuvenating Autoconf
Rejuvenating Autoconf
Rejuvenating Autoconf
No thanks for palliative care of a project that has cost gazillions of developers a lot of their time and some of their sanity
Autoconf has saved me a lot of time. The alternative would have been to manually edit Makefile, config.h etc. for every platform we build on.
the problems solved by autotools have mostly disappeared
The problems are still there. If you don't want your project to be portable between platforms, nobody is forcing you to use autoconf. Gforth has portability as one of its goals, and thanks to autoconf previous releases have been portable to a wide range of OSs and CPU architectures, and we certainly want to stay portable (although admittedly we can no longer test on as many platforms as we used to).
Rejuvenating Autoconf
Gforth is not a commercial project, either. That's why it supports portability beyond commercial considerations (e.g., 8 architectures were successfully tested on the latest release); by contrast, the most widely ported current commercial Forth implementation supports only IA-32, AMD64 (in development), ARM (32-bit) on mainstream OSs, and some embedded systems.
Rejuvenating Autoconf
Rejuvenating Autoconf
If you do not like to put the generated files in VCS, then you have to require everyone that build from the VCS to have a compatible autoconf version. This often meant not the one provided by the distro which was a pain.