Hi everybody,
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.
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.
Comments, thoughts, counter proposals, patches welcome! Patrick
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.
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.
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.
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.
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.)
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?
Nico
On Wed, 28 Oct 2020 at 12:20, Nico Huber nico.h@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. 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.
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'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".
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? 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.
Richard
On Wed, Oct 28, 2020 at 01:41:30PM +0000, Richard Hughes wrote:
On Wed, 28 Oct 2020 at 12:20, Nico Huber nico.h@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. 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.
Sounds like you are making an fwupd problem into a flashrom problem.
Luc Verhaegen.
On Wed, Oct 28, 2020 at 03:10:47PM +0100, Luc Verhaegen wrote:
On Wed, Oct 28, 2020 at 01:41:30PM +0000, Richard Hughes wrote:
On Wed, 28 Oct 2020 at 12:20, Nico Huber nico.h@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. 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.
Sounds like you are making an fwupd problem into a flashrom problem.
And "ADOPT THIS OR ELSE" is never a good look.
Luc Verhaegen.
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
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 hughsient@gmail.com wrote:
On Wed, 28 Oct 2020 at 12:20, Nico Huber nico.h@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-leave@flashrom.org
Best regards, Angel Pons Pons
On Wed, 28 Oct 2020 at 16:19, Angel Pons th3fanbus@gmail.com wrote:
It is very simple: the `-o` command-line option is unusable on the distributions which have switched to meson to build flashrom.
You've just said; the bug was fixed upstream already, I'm not sure what else I could have done other than not make the mistake in the first place. I'm not going to fight for meson support every time someone suggests removing it; if there's a consensus to rip out code to fight "technical debt" please just do it.
Richard
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 nico.h@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.
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
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.
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.
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.
Nico _______________________________________________ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-leave@flashrom.org
Hi Richard,
let me just say, you worry too much. When I say we can't drop Make and you say we can't drop Meson, then most likely nobody will drop either. Also, nobody has mentioned yet dropping one solution before the other can take over (beside you).
On 28.10.20 14:41, Richard Hughes wrote:
On Wed, 28 Oct 2020 at 12:20, Nico Huber nico.h@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.
That doesn't explain what doesn't work with the Makefile.
A lot of companies care (including Google) about using fwupd for updating
Not sure why you mention Google. Is that supposed to sound important? If flashrom's history shows anything, it's that even if the biggest IT companies rely on an open-source tool, it changes nothing for the project per se.
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.
I guess in the long run, you won't need much flashrom indeed. On Linux, it's best to do the hardware access in the kernel. Flashrom, OTOH, is focused to be multiplatform and hence does things in user space. And Linux kernel SPI drivers are catching up. Of course, I would be happy to hear that you still want to use (lib)flashrom even when all the hardware access is done in the kernel. But I also understand that there's always a trade-off.
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.
I guess you miss how big flashrom already is without the updates fwupd installs with it. Especially when you account for the thanks the pro- ject gets: It only comes from users who call flashrom directly. No fwupd, no big company using it for production.
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.
Seriously?! Ripping lines out of context and then complaining about qualification?
Nico
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 nico.h@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
On Fri, Oct 30, 2020 at 2:13 PM Nico Huber nico.h@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 nico.h@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
On 31.10.20 01:36, Rosen Penev wrote:
On Fri, Oct 30, 2020 at 2:13 PM Nico Huber nico.h@gmx.de wrote:
On 29.10.20 00:10, Rosen Penev wrote:
On Wed, Oct 28, 2020 at 5:20 AM Nico Huber nico.h@gmx.de wrote:
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.
PIP is another dependency. Not too bad, maybe even less bad than gmake.
There is no currently supported OS that has a meson or ninja version that is too old.
Supported by flashrom? or supported by Meson? in either case, is there a list?
Nico
Tossing in my $0.02
On Wed, Oct 28, 2020 at 4:19 PM Nico Huber nico.h@gmx.de wrote:
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.
That doesn't explain what doesn't work with the Makefile.
IIRC the addition of Meson was solely intended to enable an important user of flashrom, fwupd.
Instead of pushing Meson as a full replacement for Make, perhaps we can make the scope of Meson support explicit and clean up anything that doesn't fit within that scope. Something like "build libflashrom with internal programmer support for fwupd" might do. Anything beyond that must be done in the Makefile.
Would that simplify things, or would there still be too much overhead by having some limited support for meson?
-
Angel Pons -
David Hendricks -
Luc Verhaegen -
Nico Huber -
Patrick Georgi -
Richard Hughes -
Rosen Penev