Rejuvenating Autoconf

Posted Oct 24, 2020 19:55 UTC (Sat) by pbonzini (subscriber, #60935)
In reply to: Rejuvenating Autoconf by marcH
Parent article: Rejuvenating Autoconf

Yeah, indeed. QEMU has used something vaguely inspired by kbuild (but homegrown) for several users. It worked very well for the easy cases, but it was incredibly hard to extend and debug once you stepped outside the beaten path, and very soon we ended up with different ways to do the same thing depending on which part of the project you were modifying.

In the end I decided I had enough and enlisted some help so that we could switch to Meson, it has its own set of idio... syncrasies but it has an active community so that GLib, GStreamee, QEMU and everyone else can share the resources for development and design, and everybody is willing to learn from others' use cases. And this is actually the very same things that drew me to Autotools back in the 2000s. The only issue with Autotools is the dated design, but it remains in my opinion one of the most misjudged pieces of software ever. My point is that no matter if you're using Autotools or Meson or CMake, the moral is the same: your project can use your time for more interesting things than writing Makefiles.

Rejuvenating Autoconf

Posted Oct 24, 2020 20:36 UTC (Sat) by marcH (subscriber, #57642) [Link] (4 responses)

> My point is that no matter if you're using Autotools or Meson or CMake, the moral is the same: your project can use your time for more interesting things than writing Makefiles.

Makefiles and build systems in general are misjudged because they funnily gather in a single place the best and the worst of software.

The worst: obscure syntax, workarounds and other quirks, incompatibilities between toolchains and operating systems, too many layers of indirections and lack of introspection, concurrency hard to understand and debug,...

The best: when done right, a clear graph of dependencies providing a unique, high-level perspective on the entire project and optimal, split-second build times.

BTW there is performance threshold after which improvements stop being just optimizations and become features. For instance, IDEs for Java (and many others) provide 100% reliable and real-time introspection/completion/warnings/suggestions/autocorrect because they continuously compile in real-time. Good luck achieving something as good with C/C++ houses of cards made of autotools, pre-processors, slow build times and a linker and compiler that don't have a clue about each other.

I've never used it but I suspect that's why so many people like C++ in Visual Studio. Because it didn't mind getting rid of all this sort of legacy garbage?

Rejuvenating Autoconf

Posted Oct 24, 2020 21:08 UTC (Sat) by pbonzini (subscriber, #60935) [Link] (1 responses)

I reached the conclusion that people think of their build systems as "just a bunch of glue", except at some point it becomes more like quicksand. It is the last place where you think of "design" before doing something, the last place where you think of you *should* be doing something before thinking whether you could. (And while Autotools got a lot of the first part right, especially by Autoconf 2.54, they had the second part very wrong---see Libtool).

You don't notice limitations and technical debt until it's too late, and by that time the sunken cost makes it really hard to justify the change. Again drawing from my recent experience with QEMU, I am talking of 1-2 months of almost full time work for a 2M line of code program. And even then it's only a partial conversion (basically to the point where it's impossible to screw up the rest of the work and it can be done leisurely).

Rejuvenating Autoconf

Posted Oct 26, 2020 7:47 UTC (Mon) by wtarreau (subscriber, #51152) [Link]

Ah, libtool, I almost forgot about this one. Usually one of the last lines of a failed config.log... and that one is too deep into the layers to be even fixable by the end user, resulting in your project to be abandoned and the user going back to google seeking an alternative to your project.

Rejuvenating Autoconf

Posted Oct 27, 2020 15:23 UTC (Tue) by MrWim (subscriber, #47432) [Link] (1 responses)

VSCode at least uses compile_commands.json so the build-system can communicate the compilation options, etc. to the IDE. Meson and CMake support generating this format.

There's also Bear which uses LD_PRELOAD to generate the same. I guess that would work for autotools.

I've been mulling over creating a project that takes a compile_commands.json as input and generates a meson.build from it. The idea would be to make migrations to meson at least partially automated. It might even be possible to generate multiple different compile_commands.json with build options and generate a meson.build with those same options.

Rejuvenating Autoconf

Posted Dec 9, 2020 9:31 UTC (Wed) by sandsmark (guest, #62172) [Link]

> I've been mulling over creating a project that takes a compile_commands.json as input and generates a meson.build from it. The idea would be to make migrations to meson at least partially automated. It might even be possible to generate multiple different compile_commands.json with build options and generate a meson.build with those same options.

In my experience, tools like that tend to lead to more work in the end with having to clean up everything. It's usually better to at least start those kinds of transformations from the simplest representation (i. e. so you don't have to manually pattern match a bunch of compile options etc.), and even then I end up realizing I should have just started from scratch at the endi.

Even just generating a list of source files to build would lose any kind of grouping or similar (and miss files that are built conditionally).

And FWIW, because KDE has replaced the build system a couple of times there are some scripts that are/were used to create a starting point for porting from e. g. automake to cmake, here's one of them (not sure if it is useful for doing the same conversion to meson for non-KDE projects though): https://invent.kde.org/sdk/kde-dev-scripts/-/blob/master/...