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

From: David Aguilar <davvid@gmail.com>
Date: Nov 9, 2024, 12:58 UTC
Message-ID: <Zy9ckDezMSKVA5Qi@gmail.com>
In-Reply-To: <ZyjlvNJ4peffmGZ1@nand.local>

On Mon, Nov 04, 2024 at 10:18:20AM -0500, Taylor Blau wrote:

Show 13 quoted lines

> On Mon, Nov 04, 2024 at 01:17:00PM +0100, Patrick Steinhardt wrote:
> > > I admittedly have a hard time squaring the benefits and goals we have
> > > with Meson with the cost of learning a new build system, and/or moving
> > > away from Make entirely.
> >
> > I guess this depends on the exact persona you're optimizing for. There
> > are three main personas involved here:
> >
> >   - New contributors. This is a group of people that I think would
> >     benefit from Meson. They get integration with their favorite IDE,
> >     have easy ways to discover how to tweak build instructions and can
> >     use standard invocations for Meson that they might already know from
> >     other projects.

As someone that was once a New Contributor, my perception is that new contributors are more likely to be familiar with CMake due to its longer history and wider general popularity.

CMake has standard invocations and IDE integration so this isn't really a Meson-specific feature.

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 (in the same vein of the original argument for why Git uses C instead of C++).

The remainder of my reply assumes that we are targetting a general audience (in other words, including Windows users).

Disclaimer ~ I don't use Windows so I'm making some broad assumptions and generalizations about that userbase.

Show 7 quoted lines

> 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.

Show 13 quoted lines

> 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?

Show 10 quoted lines

>   - New contributors are a group that we should be optimizing for, I
>     certainly agree with you there. But I think there are a couple of
>     points that your response glosses over:
> 
>       * New contributors should be telling us what build system they
>         prefer, not the other way around. If we are going to switch to
>         using a new build system to better accommodate new contributors,
>         it should be because either (a) they have told us what doesn't
>         work with 'make', or (b) we have a bulk of evidence that new
>         contributors cannot easily build the project.

As someone that was once a New Contributor, I would be more comfortable with CMake (over Meson) because it's widespread and because it has less dependencies.

Show 11 quoted lines

>       * 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.

Furthermore, if you must have your fast Ninja builds then CMake supports that too, but, critically, it's optional. If you don't have Ninja then you can use CMake's Makefile generator. Meson, OTOH, requires Ninja. CMake seems like a more pragmatic option in that regard.

Sorry for derailing this thread to share my Meson vs. CMake opinion, but if the main con that the Meson website has to say about CMake is, "The scripting language is cumbersome to work with. Some simple things are more complicated than necessary." [1] then my general feeling is that it's not a very strong reason for Git's needs.

[1] https://mesonbuild.com/Comparisons.html#cmake

Show 6 quoted lines

>   - Packagers are something that I admittedly have less exposure to than
>     the other groups listed here, but I think my feeling there is
>     similar. While they are more likely to exercise far more parts of
>     the build system, I think we should also only be switching to a new
>     build system if there is evidence of significant, unmet needs by
>     packagers, which I have not seen.

I concur with that. As someone that deals with packaging I strongly prefer tools that have minimal dependencies, just like Git. Meson brings along extra requirements (namely Python, as I mentioned before) whereas CMake requires just a C++ compiler and Make.

On that front, Git's Make-only setup is pretty wonderful from a packager's perspective because all you need is Make, so I don't think we would ever want to ditch the Makefiles, and that's okay.

> > > I feel that if we are going to pursue Meson over CMake and/or Make, we
> > > should have a clear plan to either get rid of CMake, keep it up-to-date,
> > > or something else.

We should also have a strong reason to transition to Meson over the "something else" option of improving the CMake integration instead of trying to replace it.

Show 23 quoted lines

> > I fully agree with all you're saying here. Whatever the solution, the
> > new build system should be a proper first-class citizen and should be
> > exercised by our CI systems such that they don't silently break.
> >
> > I also agree that it's going to be a hassle to maintain three (or three
> > and a half if you count autoconf) build systems. But I don't want to
> > break any users out there by dropping everything but Meson immediately,
> > so I think we just have to accept multiple build systems as an
> > intermediate step. How exactly that would look like is certainly up for
> > debate. My take would be:
> >
> >   1. Adopt the new build system and start exercising it via CI.
> >
> >   2. Drop CMake.
> >
> >   3. Drop autoconf.
> >
> >   4. Drop Makefiles.
> >
> > This should happen over multiple releases such that every step will pull
> > in additional user groups, which will make the new build system more
> > solid overall. I could see that one step corresponds to one release
> > cycle, but I'm also happy to adapt the pacing as necessary.

My take would be:

1. Enhance CMake
2. Drop Autoconf
3. Profit?

This would not need to happen over multiple releases. There'd just be one minor or major release where (2) would happen once (1) has reached some substantial level of maturity, and that'd be it.

Arguably, we could even do (2) before (1) and it'd be fine.

Show 9 quoted lines

> I have a hard time imagining the project ever dropping its Makefile
> entirely, if for no other reason that make is available nearly
> everywhere that we want to build Git, and the Makefile is the product of
> nearly two decades of work to make it compile anywhere.
> 
> If our tree really is going to have a Makefile in it forever, then I
> think adding Meson (even if we remove CMake support) has many of the
> same challenges as the state we're in today "supporting" Make and CMake
> in parallel.

I agree, and from my outsider perspective it seems like a simpler answer would be to double-down on CMake rather than having to adopt another system and do the whole deprecation dance.

My perception is that any benefits we would get from supporting Meson would also be present with CMake, but with less effort.

That's just my opinion, though. Perhaps there are strong reasons for why Meson is a better tool for the purposes of attracting New Contributors and improving our day-to-day usage, but the benefits are not immediately obvious to me at least.

-- 
David