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=307dc5b19a7cedcab7ec2ba51bb40996411e6e59,
[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
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Attachment: signature.asc
Description: PGP signature

_______________________________________________
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

Reply via email to