Hi Richard,
calm down :-)
Nobody's ripping out anything anywhere, and the only proposed code change is to rip out the Makefile in favor of meson, and it's far from settled what will happen to that patch.
On Wed, Oct 28, 2020 at 01:41:30PM +0000, Richard Hughes wrote:
dropping meson would be a huge step backwards for people actually using flashrom in production systems and I'm sure would alter the future viability of the project.
I'm not that concerned about the viability of flashrom with regard to its choice of build systems: Apart from fwupd and potentially a few distros, I doubt many are even aware that there is meson support in the flashrom tree. Every support request I've seen for flashrom was logging make output.
As Luc stated, that particular paragraph has rather bad optics...
In my personal experience, Meson seems harder to maintain.
Seriously?! I think with a statement like that you should qualify it with the number of meson build fixes you've had to do so far.
From migrating some ancient code base from GNU make to meson, I remember that there were a couple of things to get used to, to say the least. Especially when you're experienced with GNU make it's not necessarily obvious that moving away from that to anything else is a smart move given that there's a learning curve for flashrom developers whereas in keeping the current approach has none.
I'm used to Make, and Meson (itself and the integration in flashrom) is young.
Well, it's good enough for hundreds of other much larger and older projects, including the likes of wayland, gstreamer, gtk and system.
Without delving too deep in credentialism, of your list only gtk is older than flashrom which can be traced back to a commit[0] made in November 2000.
As for larger, they also have a much larger base of paid developers, which brings us to...
I guess it comes down to if "what you are used to" v.s. "what is best for the project".
The flashrom Makefile encodes _lots_ of knowledge collected over those 20 years and isn't just a bunch of build rules but also contains the configuration side of things. Getting all that untangled and rewritten in something else is a huge investment for a project of this size and there are always risks in rewrites[1].
From that point of view I can understand the hesitation to just throw out the baby with the bathwater, especially if the main argument that is presented in favor of meson seems to be "it's new and the cool kids use it."[2]
Let me try to offer an argument for using meson: The way flashrom uses GNU make is highly unusual[3] in that it uses make for build configuration in addition to dependency tracking.
That leads to people either hesitating to change the build system (been there) or breaking it when they bring up the courage to contribute (done that). In contrast, meson provides both configuration and build (although by passing through to backends) but in an intentional design that is documented in the meson project and a notable developer usability improvement over other config + build combinations such as autotools + GNU make.
your research and found out which distros shipping flashrom are using,
Sorry but that focus on (Linux) "distros" seems somewhat limited: Flashrom is used in various embedded contexts, on *BSDs, mac OS[4] for which a driver[5] was specifically developed before that driver was adopted for coreboot tooling, Windows, Solaris, and I guess it's also usable on Linux. There are even DOS builds.
Regards, Patrick
[0] https://review.coreboot.org/cgit/coreboot.git/commit/?id=307dc5b19a7cedcab7e..., [1] See "Excuse #3" in https://www.jwz.org/gruntle/nomo.html, https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ [2] For some value of cool. [3] In my opinion flashrom's use of make is even more arcane than coreboot's, but I might be biased given that I built the latter's build system. And I know crazy when I see it: I also built significant parts of the openbios build flow and that one is based on XSLT... [4] A report that the Makefile based build fails on mac OS is what brought me to look into the build system situation in the first place. [5] https://www.coreboot.org/DirectHW