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

[Patrick Steinhardt <ps@pks.im>]

On Mon, Nov 04, 2024 at 10:18:20AM -0500, Taylor Blau wrote:
> 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.

Yes, that's certainly true. And while I think we should optimize more
for newcomers as stated, I still think that Meson is very much
preferable over Makefiles for long-time contributors, as well. The
transition period may take some time, but in the end it just feels
superior to Make from my poin of view.

Out of curiosity: did you try the Meson build? I personally have to say
that I already prefer working with it because the workflow with it is so
much nicer. It has nicer output, is faster, has out-of-tree builds,
makes it easier to configure and test execution feels way nicer compared
to my previous workflow with make.

This is all subjective of course.

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

As said, Makefiles have some problems that aren't really solveable from
my perspective. And I think part of the problem in this context is that
the typical developer working on Git is very much centered around Unix.
The experience on non-Unix systems is kind of a pain though as there is
no proper integration with anything.

And that's not only true for non-Unix-like platforms, but basically for
anyone who isn't comfortable working from the command line. Integration
of the project into an IDE with our Makefile is hard to pull off. While
many editors can of course trivially execute the Makefile for you,
setting things up such that it is _properly_ integrated into the IDE is
hard.

Overall, I don't think we old time contributors lose anything by using
Meson instead of Makefiles, quite on the contrary we get speedier builds
and nicer integration. We'd have to adapt eventually, but I don't see
that as a huge barrier.

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

That's basically why the whole patch series is marked as an RFC: to get
feedback from people and ask them for their opinion.

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

Agreed.

I assume that what they are after is a streamlined process for how to
compile and test the project. The build system should be providing good
feedback for missing dependencies, for existing build options and how to
use them. These are all things that Meson provides by default, and our
Makefile doesn't.

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

From my own experience the integration with other IDEs isn't great at
all in Makefile-based projects. I don't use IDEs though, so I am
probably not the best resource to judge.

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

We have repeatedly gotten feedback that our autoconf-based build is
basically broken and does not work well. After all, that's what spawned
the whole discussion around a more modern build system that is able to
properly auto-detect what the host system provides.

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

If our stance is that we cannot ever drop our Makefile because it has
grown for such a long time, but maintaing two official build systems at
the same time is not an option either, then our hands are tied. So I
don't think is a reasonable approach overall.

Yes, transitions like this will cause some pain, but I think that it is
relatively easy to avoid most of the pain by having a proper plan for
how to do the transition. The biggest pain will be that we have to
maintain multiple build systems and keep them in sync for some time, but
that also has a couple of advantages:

  - We can iteratively evolve the replacement build system over time
    until it is ready to fully replace the old one.

  - We don't have to screw anyone over by having a hard cutoff date.

  - We can decide that the replacement build system is insufficient and
    discard it.

  - Users of the build system can experiment with both build systems.

Patrick