Re: [RFC PATCH v4 00/19] Modernize the build system

On Mon, Nov 11, 2024 at 11:36:34AM +0100, Patrick Steinhardt wrote:

Thanks for clarifying. Not that it matters, but you've convinced me. Constructive criticism follows below in the hope that it can help you further harden the arguments for Meson.

The pain of discovering options with CMake is true in the general case.

A specific project can enforce conventions so that all option()s are specified at the top of the main build script or a designated file specifically for options. That would trivially make the options easily discoverable in that there's only a single place to look, but that's nowhere near the rigor that Meson enforces.

Following a sensible convention is why I didn't originally vibe with the argument that option()s are insufficient, but that would merely be one project's conventions and is by no means a universal practice.

Elsewhere in this thread it was also mentioned that unknown options are blindly accepted by CMake. That's actually not true.

While it's not as rigorous as Meson because it doesn't error out by default, CMake does issue a warning when you specify variables/options that are not used by the project. IIRC this warning can be made into an error by using the "cmake -Werror=dev" option, but I appreciate Meson taking the stricter route as it results in better overall usability.

I hope that's not where things land because the separation of configuration vs. build steps does provide a benefit in day-to-day use (specifically, faster incremental builds) due to the clean separation of the configuration and build steps.

It seems like it would be nice if the Meson build were eventually hooked up so that we can continue typing "make prefix=... install" (perhaps through an opt-in "enable meson" variable) and the Makefile would handle driving Meson + Ninja, but that's probably an untenable feature given the complexity of the current Makefile.

If the Makefile were completely replaced one day then that would be a nice to have, but it would probably be a bad crutch because the natural tendency would be to shadow all of Meson's options behind Makefile knobs. Encouraging users to just run meson directly seems like a better overall situation. Bisecting is the only reason why something like that might seem appealing, but I probably wouldn't push for it myself and maybe there's a better way to handle that when we cross that bridge.

Thanks both for confirming that muon is a viable alternative.

Elsewhere in this thread packaging metadata for CMake was shared arguing that CMake also has many dependencies. A subtle nuance there is that those are all either optional dependencies (e.g. Qt for the GUI parts) or they are dependencies that can be optionally supplied.

You can build CMake without those dependencies installed and CMake's vendored versions will be statically linked instead. So, from the perspective of wanting to go from 0 to 100 with just gcc/g++ installed, CMake has less dependencies. This might be slightly disingenuous because CMake vendors its dependencies and distros have to opt-in so that they can supply their own versions, but the main takeaway is that GCC is all you need and that's what I meant by, "less dependencies."

This is a moot point for most users, though, and it's even moreso moot if muon compatibility can be maintained.

As to why I consider Python a liability ~ this is more of a concern for Meson and it doesn't really matter for end users, but Python has a proven track record of making breaking changes.

If you're building everything from scratch with new versions of compilers and tools then the C++ project is the one that's going to build just fine a decade from now with little to minimal effort. Python doesn't have that track record.

Even though CMake is written in C++ (which is unacceptable for some projects), this is subjectively one advantage that CMake seems to have. This is a moot point, though, and perhaps Python will eventually reach this same level of respect for not introducing breaking changes.

Furthermore, I suspect that most contributors are simply going to "apt install meson" or "brew install meson" so it's not really that much of an issue in practice for the majority of users/contributors.

I agree with you. Meson looks to be a technically better option. I kinda wonder how many folks are actually using the contrib/ CMakeLists.txt, and whether this effort would be helped by retiring it sooner rather than later?

Would it be worth adding a canary to the CMake build that forces it to fail to build unless "cmake -D ENABLE_DEPRECATED_BUILD=ON" option is specified?

It could error out with a message telling users to reach out to the list alongside the hint to specify the option if they just want to get a working build.

On a rather low-powered machine here are some timings:

    $ make clean
    $ time make -j
    181.36s user 15.35s system 99% cpu 3:17.33 total

    $ ninja -C build clean
    $ time ninja -C build
    11.23s user 4.67s system 47% cpu 33.605 total

34s vs 3m17s ~ nice! That's also surprising.

That large of a difference is not explained by the extra probes done by the Makefile; a no-op incremental build is 0.5s for Make and 0.02s for Meson so the Makefile probes seem to only account for at most 0.5s.

Is the Meson build simply building much less, and that's why it's currently so much faster?

Or.. is it because I have "sccache" installed and Meson automatically uses it? "ninja -C build -v" confirms that it's using sccache and "make V=1" does not, so maybe that's why.

How do we disable the sccache usage? "meson configure build" doesn't seem to list anything related to caching, but it is really nice seeing all of the other options in one place.

Improvement in build time seems like it could be something that sways long-time contributors towards Meson. It is pretty nice that it automatically picked up sccache in my $PATH and automatically gave me those speedups.

Thanks. I don't want to be the CMake champion, so here are a few helpful/surprising details about the Meson build to help make it better.

(1) I first built w/out having "curl-config" installed. I was surprised to find that "ninja -C build install" ended up installing "bin/curl" and "bin/curl-config" into the prefix.

Is there a way to have the install step only install Git without bringing along these other non-Git bits?

(2) There seems to be a difference in how symlinks and hardlinks are handled in the install step.

Running "make prefix=$PWD/dist install" ends up with real files in dist/bin/ (hardlinks) whereas with Meson all of the files in the bin/ directory are symlinks into ../libexec/.

(3) Not all of the same files seems to be getting installed.

I don't see bin/gitk or bin/git-cvsserver when building with Meson.

The share/git-core/templates/ directory is missing completely.

git-gui and its related files are missing. Perhaps this is intentional/todo at this stage and hasn't been added yet.

Meson installs bin/git-http-backend (symlinked to libexec) but in the original Makefile this file only exists in libexec/.

The contents of libexec/git-core/ seems to be missing dozens of files compared to the Makefile build.

share/perl5/ has a bunch of extra git-{cvsserver,send-email,svn,...} scripts so perhaps this is where some of those files went? The Makefile places these files in the libexec/ area instead of in the share/perl5/ area.

The Makefile does not install share/gitweb/static/js/. Instead, it seems to mash everything together into a single share/gitweb/static/gitweb.js file which Meson does not install. Meson installs separate files in the share/gitweb/static/js/ area. Was that intentional, or is that just another todo?

cheers,