On 29.10.20 00:10, Rosen Penev wrote: > Comments from a user and from someone who recently transitioned the > OpenWrt package to use meson instead of make > > On Wed, Oct 28, 2020 at 5:20 AM Nico Huber <nic...@gmx.de> wrote: >> >> Hi Patrick, >> >> On 28.10.20 11:09, Patrick Georgi via flashrom wrote: >>> I just pushed https://review.coreboot.org/c/flashrom/+/46875 for >>> review which replaces the make based build process with a call to >>> use meson instead. The rationale is that the project is too small to >>> warrant having two build systems. >> >> thanks for the heads-up. IMHO, if we lack resources, we should drop >> Meson instead, it seems there's a lot to do still and with the same >> amount of effort, we could maintain Make for some years. > I disagree 100%. In OpenWrt, we have to include GNU Make as part of > the SDK as we cannot rely on the various different versions provided > by different operating systems. The one in macOS for example has bugs > that take a bit of work to work around. Easier to use GNU Make.
Well, flashrom is not OpenWrt. What I said was 100% meant in the context of flashrom. Basically extrapolating the effort of 3 years maintenance into the future. IIRC, we also assume GNU make (leave it to the user to install it, though). Apart from that, many compatibility problems have been solved by other nice people before, so there wasn't much left for me to do. So naturally, some things (probably not the same but maybe with similar effort) would have to be solved for a new system. So how could it be less effort? >> >>> There are likely reasons left to use make (e.g. build configurations >>> not yet supported by meson), so please consider this mainly an >>> opportunity to discuss where flashrom's build process is headed, >>> a warning that make _may_ be on the way out and a call to action >>> to improve the meson build system to the point where it covers all >>> build configurations. > For some of these build configurations, I have patches on GitHub as > well as this mailing list: > https://github.com/flashrom/flashrom/pulls/neheb Yeah, seen the patches on the ML. Thanks! Not sure whom to poke to get them reviewed, though. My biggest concerns are with older (LTS) distributions that might not ship Meson/Ninja or not a recent version, and of course things that maybe aren't targeted by Meson at all (mingw? djgpp?). It's been a while since I looked into the support, maybe everything is supported already and we debate for naught? (I hope so!) >> >> TL;DR We're currently able to build for libpayload, DOS, Windows >> (natively, because there are native libraries involved for at least >> one programmer) and MacOS. Please don't break that. >> >> I have to admit, I'm strongly biased towards Make here. Not because >> I don't like Meson, more because for flashrom it adds something with- >> out stating why. There were some vague requirements mentioned when >> Richard originally proposed Meson, and that the Makefile would have >> to be hacked otherwise, but nothing specific. > Maybe that's a problem with the PR. meson just has better defaults > than Make. ninja, precompiled headers, position independent code, > etc... https://mesonbuild.com/Builtin-options.html >> >> Meson, AFAIUI, is not a replacement for Make. It's more an alternative >> to the likes of GNU autotools and CMake, that don't build a program, >> but generate Makefiles. Meson doesn't produce Makefiles, instead it >> has a backend for Ninja which does Make's job then, AIUI. > Ninja typically compiles 5-15% faster than Make as tested by various > users with different CMake projects. Well, I don't doubt it. But what does it tell us about a project that avoids all that? And how much maintenance effort is a 15% compile-time improvement worse? I don't know. It's always a trade-off. >> >> So we didn't need these things before. Why do we need them now? (I >> don't want to imply that we don't need it, really just want to have >> the question answered. Sometimes things end in chaos when a solution >> is provided before a problem was stated.) > Both meson and CMake are easier to integrate with custom toolchains. Compared to what? With a plain makefile, I don't have to integrate anything, I just point it to the binaries. >> >> In my personal experience, Meson seems harder to maintain. But that's >> mostly because of two things: I'm used to Make, and Meson (itself and >> the integration in flashrom) is young. 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? > meson is younger than make, so makes sense that there's some pain. > Much better than dealing with multiple and potentially incompatible > versions though. there is only one meson. There are multiple Make > projects. Simply having a minimum version is all that's needed. That's right. I also thought about checking Meson into the flashrom repository to solve that version issue and that Meson isn't available as package for all targeted OS (again, that might not be true anymore). But then I realized that Ninja is the actual thing that was missing on most systems. Nico _______________________________________________ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
