On Mon, Nov 11, 2024 at 11:36:34AM +0100, Patrick Steinhardt wrote: > On Sat, Nov 09, 2024 at 04:58:56AM -0800, David Aguilar wrote: > > That said, if we mean, "Linux/Unix-savvy New Contributors," then > > I can understand why Meson might be a favorite, and perhaps this > > might be the crowd we are looking to target [...] > > My goal is to not only make things easier to use for Linux users, but > also for users on other platforms like Windows while also catering to > the typical developer of Git and making the solution for them as tasty > as possible. > > I agree that CMake is a tad easier to use and set up on Windows, mostly > because it is directly integrated into MSVC. But I also think that CMake > is a harder sell towards the power users because it is comparatively > hard to maintain due to its somewhat arcane syntax, implicit variables > and things like this. > > So I'm basically trying to find a good middle ground where all of the > respective target audiences get benefit: > > - For Unix devs I think that Meson is easier to maintain and use > compared to CMake. We also get nice features like out-of-source > builds, good integration with the test suite and easy integration > with IDEs. > > - For Windows devs we have an officially supported way to build Meson > from MSVC and co. Also, subprojects allow us to have as easy story > for how to build Git without preinstalled dependencies, which is not > currently possible with CMake to the best of my knowledge. > > - For packagers I think that Meson provides better discoverability of > options than CMake. > > So Meson may not be the perfect solution for everyone of these target > audiences, and better solutions may exist to cater specific needs. But > it provides a net benefit for every single one of these audiences from > my point of view. And when taking the benefits for all target audiences > combined I think that Meson provides the bigger win compared to CMake. 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. > > > Patrick Steinhardt wrote: > > > > - Packagers. This is another group of people that would benefit from > > > > my point of view. This is mostly because Meson has certain standards > > > > for how to approach problems, and thus the packager would know for > > > > how to handle things. They don't have to manually track build > > > > options and changes thereof, as these can be easily discovered and > > > > because Meson will error out in case invalid options are passed. > > > > CMake's option() variables and its GNUInstallDirs module pretty much > > handles all of the standardization that packagers are looking for on > > this front, so this argument doesn't push the needle towards Meson over > > CMake from my perspective. > > I think that discoverability of Meson is way better. Here you can simply > say `meson configure` and it provides you a nice list of all options > that are available. For CMake it always used to be a big pain. 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. > > > Taylor Blau wrote: > > > I appreciate your thoughtful response to my concerns here. Please feel > > > free to correct me if I am wrong, but I think the bulk of your argument > > > is captured fairly well by these three points, so I want to focus my > > > response here. > > > > > > Responding in turn, I think my feeling is something like: > > > > > > - Long-time Git contributors are going to be the ones who will most > > > frequently use the new build system. I am definitely sympathetic to > > > getting too comfortable with our existing tools, but so far in your > > > response I have not seen a compelling reason to switch the project > > > to use Meson. > > > > Likewise, I have not seen a compelling reason to not focus the > > effort on CMake instead. In other words, why not enhance the current > > status quo (Make + CMake) instead of trying to replace it? > > As mentioned above, I mostly think that Meson makes for a more > compelling overall package. That being said, if we eventually come to > the conclusion that we as a community want CMake instead of Meson, then > I am willing to go there. 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. > > > * New contributors do not interact with build system internals > > > nearly as much as more experienced contributors. I would imagine > > > that the vast majority of those interactions are simply running > > > "make" or "make test". > > > > > > You mention a handful of other niceties that Meson provides, > > > like language server support, but I am not sure that I agree > > > those are (a) the responsibility of the build system to provide, > > > or (b) that those needs aren't already well met by the vast > > > number of existing tools and IDE integrations that can work with > > > ctags. > > > > CMake has all of these same bells and whistles, and it's already present > > in git.git. LSP support just means being able to generate a > > compile_commands.json file, and the current CMake setup already does > > that. > > > > The one thing that no one has mentioned is dependencies. > > > > CMake has less dependencies. Python is arguably a liability in the build > > system arena, and Meson requires it. > > Eli has menitoned [muon](https://muon.build/), which is a drop-in > replacement for Meson written in plain C99. I don't know whether it is > currently able to compile the Git project, but if this is going to be a > concern for people I can try to make sure that it does. 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'd honestly be sad if we go down the CMake route, mostly because I > think that it is an inferior build system compared to Meson. I have > worked with it extensively in the context of libgit2 and always found it > to be a pain due to its esoteric syntax, the use of so many implicit > variables, platform CMake policies, and there being so many ways to do > the same thing and, where the easiest solution is typically the wrong > one to pick. > > That being said, I'm trying to be as pragmatic is possible: my main goal > is to have a modern build system that is easier to use. So while I think > that Meson fits better into that role, the next-best thing would be > CMake from my point of view. > > So I'll continue to champion Meson, but if the project as a whole agrees > to take up CMake as another official build system then I'll adapt and > make that happen. 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 for your input, highly appreciated! 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, -- David
