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

[Taylor Blau <me@ttaylorr.com>]

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:
>
>   - Long-time Git contributors. I don't worry about that persona too
>     much. Folks in this category tend to be highly skilled, and they
>     should not have much of an issue with adapting to Meson.
>
>   - 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.
>
>   - 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.

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.

    What I really want to say here is that I don't think we should be
    over-correcting on things that we are all comfortable with when they
    are indeed not the optimal solution.

    We can and should challenge those assumptions. But I think what I
    see here is us challenging the assumption that 'make' is not the
    right tool for the project, and (at least personally) not seeing
    that it isn't.

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

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

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

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.

Thanks,
Taylor