Rejuvenating Autoconf

Posted Oct 25, 2020 22:30 UTC (Sun) by Cyberax (✭ supporter ✭, #52523)
In reply to: Rejuvenating Autoconf by nix
Parent article: Rejuvenating Autoconf

I've moved several autoconf-based libraries to CMake and usually it was pretty fast. Even with complicated multi-module libraries.

> just upgrading autoconf versions is a very big job for GCC, let alone switching build systems
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).

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.
Sometimes maintenance should mean just killing it.

Rejuvenating Autoconf

Posted Oct 25, 2020 22:33 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

Mind you, the LLVM and CLang build system also allow building them as shared libraries, with example on how to use them. With full Windows support (meanwhile gcc still requires some kind of POSIX emulation on Windows to build) and ability to create project files for IDEs.

Rejuvenating Autoconf

Posted Oct 26, 2020 15:39 UTC (Mon) by nix (subscriber, #2304) [Link] (10 responses)

You think GCC could migrate to a new build system in a couple of weeks?! OK you quite clearly have *no* idea what you're talking about. It takes about a month of fiddling and testing to migrate to a new autoconf release, and that's if you're lucky and there are no painful obscure problems. A complete replacement with something else is probably at least a year's work: there's an enormous amount of baked-in knowledge in there that would all need to be transferred.

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

Rejuvenating Autoconf

Posted Oct 26, 2020 16:33 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Yes, the main problem is that CMake only supports a single toolchain per language (and it's pretty fundamental to how it works today in that pretty much everything assumes it can ask "what is the C compiler in use?" and get a sensible answer in CMake code). So self-compilation becomes an interesting question as well as separate host/target compilation in a single build. But besides those issues (which I admit are not trivial), cross compilation does work. It just disqualifies it for projects which compile some part of themselves to run on the host to generate code for the target (which are few and far between in the scheme of things). I'm not sure how LLVM/Clang does post-phase1 compilation off-hand, but it's probably a separate (possibly automated) CMake invocation to use the just-built compiler.

Rejuvenating Autoconf

Posted Oct 26, 2020 17:09 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

Yes. People over-estimate the gcc's build system complexity. It's complex, but it doesn't HAVE to be complex.

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.
Check it again.

Rejuvenating Autoconf

Posted Oct 27, 2020 14:06 UTC (Tue) by peter-b (subscriber, #66996) [Link] (6 responses)

> The bootstrap stage can be removed entirely, it serves no real purpose these days.

As an escapee from compiler development, I can absolutely assure you that compiler bootstrapping is still not merely important but essential.

Rejuvenating Autoconf

Posted Oct 27, 2020 14:57 UTC (Tue) by smurf (subscriber, #17840) [Link]

We're talking about building GCC 10.0.0.2 with GCC 10.0.0.1 here, not about building GCC with stone-age-K&R-C.

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.

Rejuvenating Autoconf

Posted Oct 27, 2020 15:23 UTC (Tue) by FraserJGordon (subscriber, #96690) [Link]

But it will haunt you forever ;)

Rejuvenating Autoconf

Posted Oct 27, 2020 18:20 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Bootstrapping is important, but not the way it's done in GCC. It's written with the expectation that the first stage can be compiled by an ancient pre-K&R C, which realistically is nonsense.

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.

Rejuvenating Autoconf

Posted Nov 20, 2020 21:51 UTC (Fri) by nix (subscriber, #2304) [Link]

That hasn't been true for years. You've needed a C++98 compiler to compile all GCCs since, IIRC, 4.8.

Rejuvenating Autoconf

Posted Oct 28, 2020 3:13 UTC (Wed) by pabs (subscriber, #43278) [Link] (1 responses)

These folks are of the opinion that bootstrapping will always be essential:

https://bootstrappable.org/

Rejuvenating Autoconf

Posted Oct 28, 2020 3:24 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Bootstrapping problem is beat by diverse double compilation. It's also deeply theoretical, nobody has demonstrated it in practice for anything non-trivial.

And it doesn't even apply here, the "boostrap" stage in GCC still requires a compiler, it just has very low requirements for it.

Rejuvenating Autoconf

Posted Oct 30, 2020 21:52 UTC (Fri) by jonesmz (subscriber, #130234) [Link]

That seems to speak more to how horrible autotools is, than to how complex the GCC build system is.