Hi list, Personally, I would prefer to keep using Make as flashrom's build system. It is what most (if not all) flashrom developers are used to, and has stood the test of time pretty well. However, every time meson has been brought up, I have perceived little interest on behalf of meson's proponents to ensure it is properly maintained. If meson advocates beg to differ, then I would request that they substantiate their stance. Having to deal with externally-imposed technical debt is not something I desire, and I highly doubt anyone else would.
On Wed, Oct 28, 2020 at 1:41 PM Richard Hughes <hughsi...@gmail.com> wrote: > > On Wed, 28 Oct 2020 at 12:20, Nico Huber <nic...@gmx.de> wrote: > > So we didn't need these things before. Why do we need them now? > > Meson makes it possible to build fwupd as a subproject of fwupd, on > any architecture, on any distro, which means we can use libflashrom on > machines that don't ship a new enough distro version. A lot of > companies care (including Google) about using fwupd for updating > system firmware, and without libflashrom being available we'd just > drop the flashrom plugin in fwupd, and in all honesty just reimplement > the required bits of flashing to SPI directly. How exactly does the build system prevent using libflashrom? If this is due to a limitation of the Makefiles, why not simply fix them? Or is it that meson is unable to build projects using Makefiles, which would simply be a deficiency of meson? Still, if flashrom's build system is somehow unsuitable to use with fwupd, there's nothing that would preclude deprecating libflashrom usage in favor of a NIH reimplementation. However, there is only one chance in production environments: just one mistake can effectively transmute many computers into highly expensive ornaments. > As a project you can do > as you like, but 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. Fallacious threats as a means to an end might have worked in the past or in other situations, but can only lead to the caster's own extinction when used here. The `-o` command-line option (essential when remotely diagnosing problems) was unusable on Debian at some point, because of a bug in the meson files. While the bug has already been addressed upstream, the broken packages still remain. Plus, since many distributions are Debian derivatives, they also have the same problem. If meson support had never been submitted, this problem would have never happened. I however agree that dropping meson support would alter the future viability of the project. Without meson, the flashrom project would have less technical debt to take care of, and the few developers in charge could spend their time and energy reviewing very useful features, such as support for flashing ATI/AMD graphics cards; c.f. https://review.coreboot.org/c/flashrom/+/29078 and follow-ups. > > 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. I had to fix meson several times, and also pushed towards having it build-tested. I agree with Nico that it is harder to maintain, primarily because no one actively does so. Experience from coreboot tells me that code with lots of users but next to no maintainers will eventually need to be scrapped. This makes users sad, but relieves developers from neglected technical debt's endless well of suffering. Having heaps of rotting code stall new features and improvements is excruciatingly noxious to one's rationality. > > 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 systemd. > I guess it comes down to if "what you are used to" v.s. "what is best > for the project". A project isn't simply a pile of code. It also comprises the people around it: the users, the maintainers, the developers... Only accounting for the objective characteristics of flashrom's codebase is not enough to decide something as fundamental as the build system for the project. > > So how about you bring the Meson > > build up-to-speed first? and once it's able to produce the same binaries > > on all platforms decide if it's working out? > > What binaries is it missing? Nico's questions do not suggest in any way that binaries are missing, but rather that they can be used to compare both build systems. One way to test meson is to check whether it is reproducible: using the same configuration options, do both build systems produce the exact same executable and library binaries? Granted, it is time-consuming to test all possible combinations of options on all platforms, but at least some testing to be done. Otherwise, we risk introducing lots of regressions which no one would then fix. > This email sounds more like "I don't > understand X, we have to rip it out for everyone". I guess you've done > your research and found out which distros shipping flashrom are using, > either the make-based version or the meson-based version. That might > help you make up your mind. It is very simple: the `-o` command-line option is unusable on the distributions which have switched to meson to build flashrom. > Richard > _______________________________________________ > flashrom mailing list -- flashrom@flashrom.org > To unsubscribe send an email to flashrom-le...@flashrom.org Best regards, Angel Pons Pons _______________________________________________ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
