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.
