Rewrite build system in Meson

[Ericson2314]

The specific features I am thinking that Autoconf lacks are

• Windows support (with and without mingw)
• Outputs Ninja or something similar

Both of these are non essential, but good for various experiments:

• Windows support obviously allows experimenting with Nix supporting windows. GCC is inadequate because it doesn't offer C++ interopt with MSVC, so Windows's many C++-only APIs are unusable.
• Outputing a dependency graph allows fun experiments with Recursive Nix (edolstra@1cfdfd7) and ninja2nix (https://github.com/awakesecurity/ninja2nix)

This lowers the list down to Meson and CMake, AFIAK. I prefer Meson because:

• It doesn't use compiler makefile generation, which avoids a regrettable ninja impurity
• It's less crufty. CMake became better, but old cmake was bad, leaving a lot of legacy cruft. Meson is a clean slate so there's no minefield of deprecated bad ways of doing things.
• Full disclosure, I've been working on improving Meson's cross compilation support, so I'm partial to it.

CC @taktoa

[taktoa]

Sadly ninja2nix doesn't really exist -- I tried my best to convert Ninja features into Nix ones using IFD where necessary, but it's just not feasible. If you want to take another crack at it using Recursive Nix, language-ninja is still quite a good library for Ninja-related stuff in Haskell. I think the feature that I couldn't figure out how to compile to IFD was depfile, but I might be mistaken.

[Ericson2314]

@taktoa But meson doesn't use depfile out of an ideological stance against dynamic dependencies / crawling the filesystem. Problem avoided!

[Ericson2314]

So the only Recursive Nix / IFD would be converting the ninja file. Everything inside should be "static Nix".

[taktoa]

This lowers the list down to Meson and CMake, AFIAK. I prefer CMake because:

s/I prefer CMake/I prefer Meson/ presumably?

[Ericson2314]

Haha yeah. thanks

[7c6f434c]

I think «Windows support with MinGW» is something Autotools have. Or you could say that one of the goals of MSYS is to support Autotools on Windows with MinGW toolchain (and I would say it generally achieves that).

[Ericson2314]

Indeed it does. But there's also MSVC and Clang/LLVM. The latter now supports the MSVC++ ABI, after Chrome and Firefox have all pushed hard on it. MinGW has a different C++ ABI (last I checked), and so is only a first class solution for C.

[7c6f434c]

I am not sure clang is hard with Autoconf and MSYS. Of course, MSVC is another story (not sure if you actually want to build Nix with it — I agree it is useful for some Windows-only or Windows-first packages).

[edolstra]

The only build system rewrite I'm down with is to a Nix-based build ("nix-make"). Anything else seems pretty much a waste of time to me.

[shlevy]

IMO nix as a build tool to build nix itself should not be a consideration of any work in the near future. At most it should be a happy accidental benefit

[7c6f434c]

Would Nix-based Nix build process make compiling Nix for the first time on an exotic (Linux-based) platform more annoying?

[vcunat]

Yes, I expect so, unless we set up some kind of automatic bootstrapping (but that probably won't be easy).

[mstone]

@vcunat: on the other hand, nix has somewhat better reflection capabilities than many alternatives. Therefore, even where cross-compiling is hard, perhaps it would still be feasible to use nix to calculate a build script suitable for the target platform.

@edolstra: regarding nix-make: have you done any additional thinking on this topic since a few years ago? (e.g., perhaps in light of https://www.microsoft.com/en-us/research/uploads/prod/2018/03/build-systems-final.pdf being published earlier this year?)

[Ericson2314]

So in the imagined Meson (or CMake) + Nix setup, there's really quite little overlap. Most of what Meson does is random domain specific logic for building C/C++ apps. Nix is a perfectly normal C++ program; there's no reason to reinvent the wheel just for Nix-based caching.

[Ericson2314]

@7c6f434c The conventional way to build Windows apps with clang is actually the clang-cl frontend which exposes a MSVC-style instead of GCC-style CLI. I'm not sure the normal GCC-style even exposes all the necessary options.

[matthewbauer]

• Autoconf should be supported on windows through MSYS.

• What's nice about autoconf is it just needs bash & gnumake to work. Meson at least pulls in an entire python runtime. We don't want to add anything more to the "common-path" than we already have:

  • coreutils
  • findutils
  • diffutils
  • gnused
  • gnugrep
  • gawk
  • gnutar
  • gzip
  • bzip2
  • gnumake
  • bash
  • patch
  • xz

[Ericson2314]

@matthewbauer

Autoconf should be supported on windows through MSYS.

But GCC doesn't support MSVC C++ ABIs. Many windows APIs are C++, and so I rather unteather us to having to stick to C ones. Who knows how deep we'd have to dig to find the right primitives for sandboxing, for example.

Updated the OP to emphasize this important point.

We don't want to add anything more to the "common-path" than we already have?

I'm confused. This common path sounds like stdenv stuff, but Nix already has non-stdenv library dependencies. Python would just be a build-time dependency, as it is for systemd and other core things that use Meson. Furthermore, if one is really in the pickle, they can stub the build platform in Meson to generate the Ninja files on a different platform than the one where it will be run. (TBH not yet implemented but I think I convinced them to let me do it.)

[coretemp]

I can't really think of any reason as to why we would want to support Windows. Windows has a less efficient kernel to do anything interesting on the platform, so it's not fit to do serious computing. So, all you are doing is porting an interesting program (Nix) to a technically inferior platform (HPC community can tell you more), which is going to increase maintenance cost.

Open-source economics imply that the owner of the project needs to see and trust that someone is going to compensate that maintenance cost or it should be made in such a way that it is easy to rip it out when you get hit by a bus or something (assuming nobody else cares about the feature).

Why did you not just fork Nix and make a Windows port dazzling us with numbers on your build system is faster and more portable, etc.? If the code is that good, I am sure it would get merged in.

[7c6f434c]

@coretemp good code with nontrivial trade-offs is quite often not merged, so it is indeed a good idea to have a discussion about limits of likely-to-be-acceptable changes.

[Ericson2314]

@coretemp so no one in this thread loves Autoconf. The consensus opinion out there is that even on Unix alone, CMake or Meson or whatever else is more maintainable (except if you need to support ancient propriety Unix, which we don't.) Now, I wouldn't push for a rewrite for that benefit alone, but certainly it should nullify any argument that a rewrite is going to hurt regular Unix users.

[coretemp]

@7c6f434c The code can be perfect at implementing something people don't even want. I just don't let that fall under "good code".

"Good code" solves a problem. Here there is, as you say a trade-off, because it is not going to solve the problem. It trades one set of problems (no Windows support) for less portability. That's the main reason this would be controversial. If it was really " good code", portability, readability, code-size, build-time, would not be impacted along with a whole list of other metrics.

I am pretty sure one could build a simple machine learning model that predicts whether a given implementation design of a feature is going to be controversial or not.

With the cross-compilation topic there was a use case for it, so it got in. If @Ericson2314 wouldn't have done it, someone else would have, because porting nixpkgs is a simple way to popularize a particular cloud vendor on a particular instruction set.

Convincing people that have literally built build-systems to do something controversial is never going to work. That's why my issues come with proper rationalization. It is not necessarily a disadvantage that Windows is not supported, but @Ericson2314 implies that this is the case. Forming a correct argument is key to getting changes you want to see in an open-source project. With the proper motivation, you can even convince others to implement the feature for you, because you have informed them that they can improve their business/life by implementing that feature.

@Ericson2314 I like the autotools including autoconf and @matthewbauer seemed to be supportive of autoconf, but I don't particularly care about what other people think when I know better and I consider democratic decisions a failure. You are just alienating the audience by saying things that just aren't true: There is no consensus that CMake is better than autoconf, not in this thread, and certainly not on the Internet.

There is zero chance of convincing me, but luckily for you, you don't have to. If this would have been my project, you would have received a lot less words. All you need to do is either convince the owner of the project, or to fork. It seems you are having little success with the former.

[7c6f434c]

readability, … would not be impacted along with a whole list of other metrics.

You say «not impacted» as if there are no trade-offs inside readability. I think there is no clear consensus whether various pieces of Perl code in Nixpkgs are readble, or whether they are more readable than natural rewrites into Shell or C… Which basically means that there is no non-controversial metric called «readability».

[Ericson2314]

less portability

Where can't Python run that anyone cares about? The original author may not love Python either, but choose it specifically for build-time portability http://mesonbuild.com/FAQ.html#why-is-meson-implemented-in-python-rather-than-programming-language-x

I agree with @7c6f434c. Any opinionated metric will just flood this thread. The facts are:

1. Python runs everywhere that Nix supports today
2. No one needs to read or write Python to use Meson or CMake, so anyone's hatred of that language should not be relevant.
3. Windows C++ APIs are inaccessible from MinGW/GCC.

[Mic92]

4. Both meson + cmake can nativly generated compile_commands.json which can be used by IDEs/editors/code analsys to figure out how to compile code
5. Ninja builds faster then make, at least meson is configuring faster (experienced that when systemd was upgraded)
6. No longer need to maintain platform dependent code to create executable: https://github.com/NixOS/nix/blob/master/mk/libraries.mk
7. Better error messages if libraries/headers are not found (relevant for users that have to compile meson nix themselves)
8. Less flacky build dependency rules: c651b7b

[Ericson2314]

(relevant for users that have to compile meson themselves)

I believe you mean Nix itself, haha. But great list!

[Ericson2314]

Maybe the thing to so is just do the conversion in a PR, and let people try out those sweet fast rebuilds for themselves.

[Mic92]

I would not recommend to do that without any blessing from the Nix core team as empirically this could be wasted effort.
Update this was not meant as critic I just wanted to avoid frustration upfront.

[coretemp]

@7c6f434c Yes, you picked out one metric that has no consensus. The rest of the argument still applies.

@Mic92 Creates his own independent argument (with some relevant information, so that's good), but it does not and cannot address the portability side of the equation.

@Ericson2314 Just ignores the portability side of the argument, which is generally not a good way to convince people. And then he alludes to the designers of Meson as if they are an authority 🤣.

[7c6f434c]

Ok, just for completeness.

Build time. This is not a single metric but a trade-off, because some ways to get better CPU utilisation for the actual compile can make storage unhappy.

Portability. This is a trade-off, because you need to assign weights to Windows support, OpenBSD support and Linux-on-exotic-CPU support. I wonder if «probability of surviving Apple SDK update» is also a possible part of the portabilty trade-off.

Code-size — is it token count (depending on the parser some things might count or not, so it is not a single objective metric) that ignores cyclomatic complexity? Also, if there is a feature (or platform support) improvement, you won't get a consensus that code size is not allowed to increase.

PS. Speaking of portability — significantly editing GitHub comment after initial creation is not too portable, because it breaks email notifications with high probability. And rendering a GitHub page requires a larger client-side codebase than just handling an email.

[Ericson2314]

@Mic92 to be clear I was going to make the PR not out of stubbornness, but because I also want to do the windows experiments I deem blocked on this.

[Ericson2314]

Started working on a meson version here in #2613

[bhipple]

Please don't make Nix depend on nix-make; doing so would make bootstrapping a raw from-source build of Nix significantly more complicated, and we'd have to continue to maintain all of the autotools build scripts for that purpose. This is not just a considerations for "exotic linux distros" but also for standard Debian or CentOS packaging as well, and a thorn in the side of initiatives like https://reproducible-builds.org/ that are trying to build everything from source with as few pre-built binaries as possible.

I can understand @NixOS/nix-core not wanting to spend their time shaving the build-system yak. Autotools seems to be doing OKish as it is, but if @Ericson2314 wants to do it it seems like a nice thing for the community and I hope it gets a serious review/consideration! Either cmake or meson would be faster to compile, have better error messages, and support things like clang compilation databases for YCM and other LLVM tools. Modern C++ build system tooling has come a long way in the last decade and it'd be nice to take advantage of it!

[stale]

I marked this as stale due to inactivity. → More info

[Mic92]

Looks like this is not going to happen?

[Ericson2314]

Trending nowhere at the moment, but I soon as well keep this issue open as it hasn't been totally shot down either and I remain hopeful.

[stale]

I marked this as stale due to inactivity. → More info

[Ericson2314]

#10378 started this, as a trial. NixOS/rfcs#132 tracks what to do next.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2024-06-05-nix-team-meeting-minutes-150/46583/1

[roberth]

We're inching closer to the point where we can remove the autoconf/make files.

I've made a start to track things to be done, while I was reviewing. This is not exhaustive at all, so feel free to edit and add items.

TODO when removing makefiles:

• remove pkg-config .in files
• delete make stuff "line by line" so we don't have dangling stuff like those pkg-config .in files

TODO:

• functional tests derivation (might even use simple make to control parallelism)
• either
  • use globs
  • or check completeness of file lists, especially in tests, because forgetting a compilation unit does not result in an error there!
    • some quick and dirty grepping?
    • maybe a pre-commit hook exists? and that'd auto fill it?
• testresults => GTEST_OUTPUT=xml:$$out/libfetchers-tests.xml
• fileset helper for libstore test runner data subpath thing: @roberth https://github.com/NixOS/nix/pull/10973/files#r1664855528
• meson: host_machine.system() isn't our SYSTEM #10957
• -Wdeprecated #10906
• Close config.h is missing following the hacking guide: #10979
• Remove quickBuild attr from VM tests; untested derivations are readily available and shared with tested derivations

[fogti]

regarding "check completeness of file lists in tests", do I understand correctly that this should be mostly e.g. such:

libexpr-tests_SOURCES := \
    $(wildcard $(d)/*.cc) \
    $(wildcard $(d)/value/*.cc) \
    $(wildcard $(d)/flake/*.cc)

blocks in local.mk files (in the current version, which would have to be ported)?

For such globbing, it is possible to use helper scripts which evaluate wildcards instead... https://stackoverflow.com/questions/34441673/can-you-glob-source-code-with-meson