[GH-ISSUE #4642] Switch from autotools to meson

gitea-mirror commented

2026-05-05 09:24:03 -06:00

Owner

Originally created by @rusty-snake on GitHub (Oct 26, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4642

This came up in https://github.com/netblue30/firejail/issues/4633#issuecomment-950317130. I like the idea. Meson is faster and has an simpler and less error-prone syntax. Is this something we want to do?

CMake would be a second alternative.

Originally created by @rusty-snake on GitHub (Oct 26, 2021). Original GitHub issue: https://github.com/netblue30/firejail/issues/4642 This came up in https://github.com/netblue30/firejail/issues/4633#issuecomment-950317130. I like the idea. Meson is faster and has an simpler and less error-prone syntax. Is this something we want to do? CMake would be a second alternative.

gitea-mirror added the

enhancement

label 2026-05-05 09:24:03 -06:00

gitea-mirror commented

2026-05-05 09:24:05 -06:00

Author

Owner

@topimiettinen commented on GitHub (Oct 26, 2021):

+1
I'm still learning Meson but it seems so much better than autoconf + configure + Make. There are also bonus stuff like support for clang scan-build, integrated tests and test coverage analysis.

@topimiettinen commented on GitHub (Oct 26, 2021): +1 I'm still learning Meson but it seems so much better than autoconf + configure + Make. There are also bonus stuff like support for `clang scan-build`, integrated tests and test coverage analysis.

gitea-mirror commented

2026-05-05 09:24:06 -06:00

Author

Owner

@rusty-snake commented on GitHub (Oct 29, 2021):

MWE 1, compile firejail
MWE 2, run firejail --noprofile echo Hi

@rusty-snake commented on GitHub (Oct 29, 2021): [MWE 1, compile firejail](https://github.com/rusty-snake/firejail/commit/f681c9726dc932b7b0f9fea805a6a234f081da3a) [MWE 2, run `firejail --noprofile echo Hi`](https://github.com/rusty-snake/firejail/commit/51354da8a4bcefb810f0ea82c0bd6832688fae16)

gitea-mirror commented

2026-05-05 09:24:07 -06:00

Author

Owner

@kmk3 commented on GitHub (Oct 31, 2021):

Switch from autotools to meson

@rusty-snake commented on Oct 26:

This came up in #4633
(comment).
I like the idea. Meson is faster

and has an simpler and less error-prone syntax.

I find the core of the syntax of autotools and make to be rather simple. In
the case of make there are some terse operator-looking internal macros (e.g.:
$<) that are easy to forget, but usually only a few of them are used and IMO
they aren't overused in this repo anyway.

I'll post a make guide later in a new thread to show what I mean.

Is this something we want to do?

CMake would be a second alternative.

I think it would be a great loss to break building with the traditional/more
portable build tools (I'll expand on this later).

The benefits of supporting alternative build systems isn't very clear either.
As for the speed, what are the workflows in question and the benchmark results?
Was make tested with something like -j$(nproc)?

@kmk3 commented on GitHub (Oct 31, 2021): > Switch from autotools to meson @rusty-snake commented [on Oct 26](https://github.com/netblue30/firejail/issues/4642#issue-1036210905): > This came up in [#4633 > (comment)](https://github.com/netblue30/firejail/issues/4633#issuecomment-950317130). > I like the idea. Meson is faster > and has an simpler and less error-prone syntax. I find the core of the syntax of autotools and make to be rather simple. In the case of make there are some terse operator-looking internal macros (e.g.: `$<`) that are easy to forget, but usually only a few of them are used and IMO they aren't overused in this repo anyway. I'll post a `make` guide later in a new thread to show what I mean. > Is this something we want to do? > > CMake would be a second alternative. I think it would be a great loss to break building with the traditional/more portable build tools (I'll expand on this later). The benefits of supporting alternative build systems isn't very clear either. As for the speed, what are the workflows in question and the benchmark results? Was `make` tested with something like `-j$(nproc)`?

gitea-mirror commented

2026-05-05 09:24:08 -06:00

Author

Owner

@rusty-snake commented on GitHub (Oct 31, 2021):

I find the core of the syntax of autotools and make to be rather simple.

The syntax of Makefiles is simple but

it is not always intuitive to read, example: $(subst test-,,$@) vs. 'foobar'.replace("test-", "")
can be very detailed
maintaining (dist)clean and uninstall targets is often forgotten
configure.ac is ugly

I'll post a make guide later in a new thread to show what I mean.

👍

Suggestion: https://github.com/netblue30/firejail/discussions/categories/show-and-tell

I think it would be a great loss to break building with the traditional/more
portable build tools (I'll expand on this later).

Two things to add (before you expand this)

We can keep autotools (i.e. you can choose which one you use)
IMHO portability isn't a problem. I wouldn't say meson has high requirements and we do not need to support legacy systems on which firejail doesn't work.

autotools is portable to legacy systems while meson is portable to windows and cross compile. IMHO we don't care about both.

As for the speed, what are the workflows in question and the benchmark results?
Was make tested with something like -j$(nproc)?

https://mesonbuild.com/Simple-comparison.html

@rusty-snake commented on GitHub (Oct 31, 2021): > I find the core of the syntax of autotools and make to be rather simple. The syntax of `Makefile`s is simple but 1. it is not always intuitive to read, example: `$(subst test-,,$@)` vs. `'foobar'.replace("test-", "")` 2. can be very detailed 3. maintaining (dist)clean and uninstall targets is often forgotten 4. configure.ac is ugly > I'll post a make guide later in a new thread to show what I mean. :+1: Suggestion: https://github.com/netblue30/firejail/discussions/categories/show-and-tell > I think it would be a great loss to break building with the traditional/more portable build tools (I'll expand on this later). Two things to add (before you expand this) 1. We can keep autotools (i.e. you can choose which one you use) 2. IMHO portability isn't a problem. I wouldn't say meson has high requirements and we do not need to support legacy systems on which firejail doesn't work. - autotools is portable to legacy systems while meson is portable to windows and cross compile. IMHO we don't care about both. > As for the speed, what are the workflows in question and the benchmark results? Was make tested with something like -j$(nproc)? https://mesonbuild.com/Simple-comparison.html

gitea-mirror commented

2026-05-05 09:24:08 -06:00

Author

Owner

@rusty-snake commented on GitHub (Oct 31, 2021):

The benefits of supporting alternative build systems isn't very clear either.

I know not all are strong arguments / arguments for meson or against autotools in general

Features like --enable-sanitizer= or fatal-warnings are integrated and don't need to be written.
meson is faster (admittedly firejail is small enough to not note a big difference)
Our current build setup fells like a "don't touch it, it works"
- We have dead targets for 6 year in Makefile.in
- Edit configure.ac and forget to commit configure ...
- Edit configure.ac and generate configure with a different version ...
- enable-contrib-install has a broken logic for years
- Do we really link against pthread and don't use it?
https://taint.org/2011/02/18/001527a.html
A lot of leading linux projects have switch from autotools to meson (systemd, Xorg, Wayland, GNOME, ...)
https://web.archive.org/web/20190706015735/https://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/ (the author is a meson developer AFAIK)
https://stackoverflow.com/questions/4071880/what-are-the-differences-between-autotools-cmake-and-scons

$ make distclean; LC_ALL=C date && (./configure && make) >/dev/null && LC_ALL=C date
Sun Oct 31 22:29:47 CET 2021
Sun Oct 31 22:30:02 CET 2021
=> 15sec

$ make distclean; LC_ALL=C date && (./configure && make -j"$(nproc)") >/dev/null && LC_ALL=C date
Sun Oct 31 22:31:25 CET 2021
Sun Oct 31 22:31:32 CET 2021
=> 7sec

$ rm -rf _builddir; LC_ALL=C date && (meson _builddir && ninja -C _builddir) >/dev/null && LC_ALL=C date
Sun Oct 31 22:32:32 CET 2021
Sun Oct 31 22:32:38 CET 2021
=> 6sec

$ make distclean; LC_ALL=C date && (./configure && make && touch src/firejail/main.c && make) >/dev/null && LC_ALL=C date
Sun Oct 31 22:39:08 CET 2021
Sun Oct 31 22:39:25 CET 2021
=> 17sec

$ make distclean; LC_ALL=C date && (./configure && make -j"$(nproc)" && touch src/firejail/main.c && make -j"$(nproc)") >/dev/null && LC_ALL=C date
Sun Oct 31 22:42:36 CET 2021
Sun Oct 31 22:42:44 CET 2021
=> 8sec

$ rm -rf _builddir; LC_ALL=C date && (meson _builddir && ninja -C _builddir && touch src/firejail/main.c && ninja -C _builddir) >/dev/null && LC_ALL=C date
Sun Oct 31 22:44:20 CET 2021
Sun Oct 31 22:44:27 CET 2021
=> 7sec

==> firejail is to small to see a big difference (if you type make -j4<ENTER>; meson: nin<TAB><ENTER>; reality: <UP><ENTER>)

@rusty-snake commented on GitHub (Oct 31, 2021): > The benefits of supporting alternative build systems isn't very clear either. _I know not all are strong arguments / arguments for meson or against autotools in general_ - Features like `--enable-sanitizer=` or `fatal-warnings` are integrated and don't need to be written. - meson is faster (admittedly firejail is small enough to not note a big difference) - Our current build setup fells like a "don't touch it, it works" - We have dead targets for 6 year in Makefile.in - Edit `configure.ac` and forget to commit `configure` ... - Edit `configure.ac` and generate `configure` with a different version ... - `enable-contrib-install` has a broken logic for years - Do we really link against pthread and don't use it? - https://taint.org/2011/02/18/001527a.html - A lot of leading linux projects have switch from autotools to meson (systemd, Xorg, Wayland, GNOME, ...) - https://web.archive.org/web/20190706015735/https://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/ (the author is a meson developer AFAIK) - https://stackoverflow.com/questions/4071880/what-are-the-differences-between-autotools-cmake-and-scons --- ``` $ make distclean; LC_ALL=C date && (./configure && make) >/dev/null && LC_ALL=C date Sun Oct 31 22:29:47 CET 2021 Sun Oct 31 22:30:02 CET 2021 => 15sec ``` ``` $ make distclean; LC_ALL=C date && (./configure && make -j"$(nproc)") >/dev/null && LC_ALL=C date Sun Oct 31 22:31:25 CET 2021 Sun Oct 31 22:31:32 CET 2021 => 7sec ``` ``` $ rm -rf _builddir; LC_ALL=C date && (meson _builddir && ninja -C _builddir) >/dev/null && LC_ALL=C date Sun Oct 31 22:32:32 CET 2021 Sun Oct 31 22:32:38 CET 2021 => 6sec ``` ``` $ make distclean; LC_ALL=C date && (./configure && make && touch src/firejail/main.c && make) >/dev/null && LC_ALL=C date Sun Oct 31 22:39:08 CET 2021 Sun Oct 31 22:39:25 CET 2021 => 17sec ``` ``` $ make distclean; LC_ALL=C date && (./configure && make -j"$(nproc)" && touch src/firejail/main.c && make -j"$(nproc)") >/dev/null && LC_ALL=C date Sun Oct 31 22:42:36 CET 2021 Sun Oct 31 22:42:44 CET 2021 => 8sec ``` ``` $ rm -rf _builddir; LC_ALL=C date && (meson _builddir && ninja -C _builddir && touch src/firejail/main.c && ninja -C _builddir) >/dev/null && LC_ALL=C date Sun Oct 31 22:44:20 CET 2021 Sun Oct 31 22:44:27 CET 2021 => 7sec ``` ==> firejail is to small to see a big difference (if you type `make -j4<ENTER>`; meson: `nin<TAB><ENTER>`; reality: `<UP><ENTER>`)

gitea-mirror commented

2026-05-05 09:24:08 -06:00

Author

Owner

@matu3ba commented on GitHub (Oct 31, 2021):

Also: + Automatic generation of pkg-config for code reusage in third-party projects.

How much maintenance will this save vs (experience) how to debug broken build stuff, ie the typical features vs bugs + debugging tradeoff. Are there any experience reports on this kind of stuff for meson?
Who from the maintainers has how much knowledge in (fixing stuff in) meson?

Personally I would prefer a low-level build library, since that reduces code to a minimum, while sharing testing with most projects. But unfortunately the only project that attempts this (and a pile of other stuff) is a few years from stable.

@matu3ba commented on GitHub (Oct 31, 2021): Also: + Automatic generation of [pkg-config](https://mesonbuild.com/Pkgconfig-module.html) for code reusage in third-party projects. 1. How much maintenance will this save vs (experience) how to debug broken build stuff, ie the typical features vs bugs + debugging tradeoff. Are there any experience reports on this kind of stuff for meson? 2. Who from the maintainers has how much knowledge in (fixing stuff in) meson? Personally I would prefer a low-level build library, since that reduces code to a minimum, while sharing testing with most projects. But unfortunately the only project that attempts this (and a pile of other stuff) is a few years from stable.

gitea-mirror commented

2026-05-05 09:24:09 -06:00

Author

Owner

@reinerh commented on GitHub (Nov 2, 2021):

We currently also have a lot of redundancy in our Makefile.in files (and some are not even in sync with others). And they are "buggy", as the object targets miss stuff like CPPFLAGS, the linking targets miss CFLAGS etc... common.mk.in is also a bit of a mess.
I think in our current build system there is already a lof of room for improvement (maybe using automake would there a bit).

I don't have much experience with meson, but from what I heard/read it's one of the better build systems. (Personally I find it only a bit annoying that it's needed to list all source files (afaik), instead of letting it use all sources in the directory.)

But I'm fine with using either of them.

@reinerh commented on GitHub (Nov 2, 2021): We currently also have a lot of redundancy in our `Makefile.in` files (and some are not even in sync with others). And they are "buggy", as the object targets miss stuff like `CPPFLAGS`, the linking targets miss `CFLAGS` etc... `common.mk.in` is also a bit of a mess. I think in our current build system there is already a lof of room for improvement (maybe using automake would there a bit). I don't have much experience with meson, but from what I heard/read it's one of the better build systems. (Personally I find it only a bit annoying that it's needed to list all source files (afaik), instead of letting it use all sources in the directory.) But I'm fine with using either of them.

gitea-mirror commented

2026-05-05 09:24:10 -06:00

Author

Owner

@rusty-snake commented on GitHub (Nov 2, 2021):

Personally I find it only a bit annoying that it's needed to list all source files (afaik), instead of letting it use all sources in the directory.

https://mesonbuild.com/FAQ.html#why-cant-i-specify-target-files-with-a-wildcard
https://mesonbuild.com/FAQ.html#but-i-really-want-to-use-wildcards

@rusty-snake commented on GitHub (Nov 2, 2021): > Personally I find it only a bit annoying that it's needed to list all source files (afaik), instead of letting it use all sources in the directory. https://mesonbuild.com/FAQ.html#why-cant-i-specify-target-files-with-a-wildcard https://mesonbuild.com/FAQ.html#but-i-really-want-to-use-wildcards

gitea-mirror commented

2026-05-05 09:24:11 -06:00

Author

Owner

@amano-kenji commented on GitHub (Jun 10, 2022):

Meson seems far simpler than cmake.

@amano-kenji commented on GitHub (Jun 10, 2022): Meson seems far simpler than cmake.

gitea-mirror commented

2026-05-05 09:24:11 -06:00

Author

Owner

@eli-schwartz commented on GitHub (Jun 12, 2022):

I think it would be a great loss to break building with the traditional/more
portable build tools (I'll expand on this later).

I had a recent discussion with a sourceware project maintainer about build systems... it included this rather insightful comment about why autotools is a highly preferable build system:

I only prefer autotools because bzip2 is used on such ancient systems. There are not many other projects it is still advantageous to have some ancient pre-unix-wars setup to run on :)

This isn't really a problem with projects that only support Linux. Of course, neither is it relevant that Meson, unlike autotools, has good support for Windows.

Since portability doesn't actually matter in the slightest, maybe the real issue is about build system requirements? autotools famously has none, which is another way of saying that it requires make but assumes you have it already (Linux will always have the other POSIX shell tools needed to run ./configure). Meson requires python, which is... common, and should always be trivial to get, but may not be preinstalled in minimal environments, and may require 50mb of disk space if you don't have it.

If that is the concern here, you may be interested in https://sr.ht/~lattis/muon/, a c99 reimplementation of Meson with good coverage for the core Meson functionality, which bootstraps with sh and a c99 compiler plus samurai (that itself bootstraps with make) and can compile down to a single statically linked prebuilt binary with an internal copy of samurai (ninja-compatible build tool which Meson uses instead of make) thrown in for good measure... all weighing in at 4.5 mb.

@eli-schwartz commented on GitHub (Jun 12, 2022): > I think it would be a great loss to break building with the traditional/more > portable build tools (I'll expand on this later). I had a recent discussion with a sourceware project maintainer about build systems... it included this rather insightful comment about why autotools is a highly preferable build system: > I only prefer autotools because bzip2 is used on such ancient systems. There are not many other projects it is still advantageous to have some ancient pre-unix-wars setup to run on :) This isn't really a problem with projects that only support Linux. Of course, neither is it relevant that Meson, unlike autotools, has good support for Windows. Since portability doesn't actually matter in the slightest, maybe the real issue is about build system requirements? autotools famously has none, which is another way of saying that it requires make but assumes you have it already (Linux will always have the other POSIX shell tools needed to run `./configure`). Meson requires python, which is... common, and should always be trivial to get, but may not be preinstalled in minimal environments, and may require 50mb of disk space if you don't have it. If that *is* the concern here, you may be interested in https://sr.ht/~lattis/muon/, a c99 reimplementation of Meson with good coverage for the core Meson functionality, which bootstraps with sh and a c99 compiler plus samurai (that itself bootstraps with make) and can compile down to a single statically linked prebuilt binary with an internal copy of samurai (ninja-compatible build tool which Meson uses instead of make) thrown in for good measure... all weighing in at 4.5 mb.

gitea-mirror commented

2026-05-05 09:24:11 -06:00

Author

Owner

@amano-kenji commented on GitHub (Jun 12, 2022):

Firejail targets desktop linux market. You can expect desktop machines to have at least 4GB RAM and 128GB storage space.

If you can't run firefox on your machine, you are not a target market.

If your computing environment is limited, then you don't need to worry about sandboxing.

@amano-kenji commented on GitHub (Jun 12, 2022): Firejail targets desktop linux market. You can expect desktop machines to have at least 4GB RAM and 128GB storage space. If you can't run firefox on your machine, you are not a target market. If your computing environment is limited, then you don't need to worry about sandboxing.

gitea-mirror commented

2026-05-05 09:24:12 -06:00

Author

Owner

@eli-schwartz commented on GitHub (Jun 12, 2022):

In my experience the concern usually tends to be less about "unable" and more "don't want to".

It's not all that unreasonable of an opinion. Most users will get it from a distro package, and distros almost always build in stripped down environments.
Also, some people may just not have any personal use for python. "Why install a large programming language stack if you don't need it" is a common refrain. If it's something you don't have already, it's also something you need to download, and bandwidth is, in many parts of the world, a big issue, far bigger than disk space or computing power.

This is why options are nice. Not everyone has to care about this, but if you do... then python isn't your only option to build stuff with Meson.

@eli-schwartz commented on GitHub (Jun 12, 2022): In my experience the concern usually tends to be less about "unable" and more "don't want to". It's not all that unreasonable of an opinion. Most users will get it from a distro package, and distros almost always *build* in stripped down environments. Also, some people may just not have any personal use for python. "Why install a large programming language stack if you don't need it" is a common refrain. If it's something you don't have already, it's also something you need to download, and bandwidth is, in many parts of the world, a *big* issue, far bigger than disk space or computing power. This is why options are nice. Not everyone has to care about this, but if you do... then python isn't your only option to build stuff with Meson.

gitea-mirror commented

2026-05-05 09:24:12 -06:00

Author

Owner

@amano-kenji commented on GitHub (Jun 12, 2022):

Python is a build dependency. Binary distro users don't need to install python.

distros almost always build in stripped down environments.

"Stripped down" in disto build environment means self-imposed sandboxes. Not artificial resource constraints like restrictions on RAM size. Build machines tend to have a lot of RAM because they need to build chromium and firefox every few weeks.

You don't need to worry about installing python if you are not using source-based distros like gentoo linux. If you are on gentoo, you should have more than 32GB RAM and 256GB storage space anyway.

My build machine has enough power to browse the internet and watch youtube videos while building chromium browser. Firefox build routinely consumes 16GB RAM while I'm browsing the internet and watching videos.

Deficient machines aren't fit to be build machines. Use a binary distro if your computer is weak.

@amano-kenji commented on GitHub (Jun 12, 2022): Python is a build dependency. Binary distro users don't need to install python. > distros almost always build in stripped down environments. "Stripped down" in disto build environment means self-imposed sandboxes. Not artificial resource constraints like restrictions on RAM size. Build machines tend to have a lot of RAM because they need to build chromium and firefox every few weeks. You don't need to worry about installing python if you are not using source-based distros like gentoo linux. If you are on gentoo, you should have more than 32GB RAM and 256GB storage space anyway. My build machine has enough power to browse the internet and watch youtube videos while building chromium browser. Firefox build routinely consumes 16GB RAM while I'm browsing the internet and watching videos. ![power](https://user-images.githubusercontent.com/106365348/173258579-0cae7c60-2b7d-4d08-be84-aff50303d766.png) Deficient machines aren't fit to be build machines. Use a binary distro if your computer is weak.

gitea-mirror referenced this issue

2026-05-05 10:21:21 -06:00

[PR #2735] [MERGED] Extend profile.template with comments #4502

Rows
Columns

[GH-ISSUE #4642] Switch from autotools to meson #2735