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