On Fri, Oct 30, 2020 at 2:13 PM Nico Huber <nic...@gmx.de> wrote: > > 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!) For older distributions, there is PIP. > > >> > >> 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. Right. PIP can solve the meson issue.
There is no currently supported OS that has a meson or ninja version that is too old. > > Nico _______________________________________________ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
