A Tale of Three Build Systems

This is not a detailed technical explanation as to the rationale, but rather outlines some of the reasons why fvwm has officially moved away from autotools.

Timeline

Fvwm is one of X11's oldest window managers. As such, its history predates a lot of changes to more modern build tools. Indeed, fvwm started out with just having a few hand-crafted Makefiles.

In 1998, someone called steve converted these Makefiles to autotools version 2.12 released in 1996. See commit b657ebb. This was at a time when the configure script was named just that. There was no configure.ac at this point.

Indeed, even around 1998, fvwm would have been seeing more interest cross-platform, especially around Solaris, *BSD, VAX, etc., and maintaining these hand-crafted Makefiles would have become difficult especially as the toolchains between these systems won't have been common; Solaris is well-known for having a different C compiler, compared to the more likely GCC variants across those other systems.

In 2006, Dominik Vogt updated fvwm to use autotools-2.53 which meant using ./configure.ac -- see commit 0f9bc15.

Between then and 2024, autotools continued as the build tool of choice in the fvwm project.

Considering Alternatives

In 2020, autoconf 2.70 was released. This introduced a number of significant changes to some of the core m4 macros autotools was using. Indeed, for a project of its age, those changes represented something of a headache, as they're tightly ingrained in how fvwm has been developed over the years. Because of its age, it was going to be a lot of work to change some of these macros, to clean up a lot of self-written m4 code which previously was required for older autotools versions.

As a side-note, the previous autoconf version prior to 2.70 being released (2.69), was in 2012. Hence, the 2.70 release represented eight years worth of changes!

This work could have been done, but it was known that other build systems existed, some of which were touted to be smaller in scope, and perhaps "faster" than autotools.

CMake

In looking at alternatives, CMake was considered. This is used in quite a few projects (neovim uses it, for example). But this wasn't offering much more than autotools did, and instead made the complexity of Makefile maintainership harder.

Meson

This was chosen primary because X11 itself is transitioning its projects from autotools to meson. Additionally, there has been good help from the wider community around meson's adoption.

In terms of "speed", the parallelised nature of not using make does mean compilation speeds are improved, even on lower-end systems.

For example, here's some compilation times. Note that this is merely indicative of potential improvements to developers and packagers:

autotools:

( ./autogen.sh && ./configure --enable-golang --enable-mandoc && make -j; )

108.62s user 26.21s system 332% cpu 40.594 total

meson:

( meson setup --reconfigure build -Dmandoc=true && meson compile -C build; )

34.12s user 11.04s system 828% cpu 5.452 total

muon:

( muon setup -Dmandoc=true build && muon samu -C build; )

48.31s user 15.12s system 905% cpu 7.002 total

Planned Support and Obsolescence

As of fvwm3-1.1.1, the default supported build system will be meson.

This means, it's the build system which is being predominately used for CI, as well as creating release tarballs.

Maintaining two build systems though is an unnecessary burden for any project maintainer.

Therefore, once fvwm3-1.1.1 has been released, that will mark a six month countdown from which autotools and meson will be maintained side-by-side, but after which autotools will be removed from fvwm3's codebase*, making meson the only option for building fvwm3.

FAQs

• I like autotools. It just works, requiring only sh, make as dependencies. Meson uses python3 which my system doesn't have.

  • Indeed. muon exists (https://muon.build) and works with fvwm3 as of muon-0.13 onward. muon is written in C and only needs to be built using a C compiler. It has an internal implementation of the ninja backend which it uses for compilation.

• Isn't this going to cause significant churn for downstream package maintainers?

  • Possibly, but meson is used across lots of different Linux systems already. We've tried to change this in such a way that there's minimal changes for packagers of fvwm3 which switching to using meson.