Hi Hugh,
On 03.01.2019 12:23, Richard Hughes wrote:
First, happy new year and I hope you all had a great break.
Thanks, you too.
As some of you know, I've been working with 3mdeb for the last few months, with the aim of using libflashrom in fwupd to be able to flash firmware using the LVFS on various embedded systems. This /could/ include flashrom-compatible consumer hardware in the future, although I've not worked out all the details on how something like coreboot-on-thinkpad could be distributed automatically. Anyway, I digress.
The fwupd project has to build in all kinds of odd targets, e.g. for odd endians, odd instruction sets,
Ah yes, that's why we avoided autotools and hacked our own makefile logic. Autotools break too often even for the trivial case (various Linux distributions on x86).
and in odd ways, e.g. installing with a prefix of /app for projects like flatpak. We also have other "robustness" guarantees and therefore have a comprehensive set of CI tests which enable a lot of warning flags and run linting and static analysis code like Coverity. This might explain my ongoing effort to fix up seemingly benign warnings.
The warning fixes are much appreciated. That's the reason why we worked pretty early on llvm/clang support for flashrom, and clang found quite a few bugs in the codebase. There are some places where some gcc versions are stupid and cause spurious warnings for certain valid compile options, so eliminating all warnings is not going to be possible with all gcc versions.
Rather than hack the hell out of Makefile (which I started to do initially) I ported the codebase to use the meson build-system. Meson is a(nother) next-generation build system used by a lot of open source projects ranging from low level libraries to desktop software. As part
Mh. We investigated CMake quite some time ago and decided against it. Not because of direct CMake problems (IIRC CMake worked really well), but because a sufficiently recent CMake was not available on all supported platforms, most notably old RHEL versions. Back then, forcing users to install build tools not available on their platform of choice was frowned upon. Is Meson available by default on the oldest supported RHEL version? If not, we'll have to recheck if the RHEL versions with a too ancient CMake have since been retired.
of the port, I also copied the CONFIG_ logic from the makefile, e.g.
Option Current Value Possible Values Description
config_atahpt false [true, false] Highpoint (HPT) ATA/RAID controllers config_atapromise false [true, false] Promise ATA controller config_atavia true [true, false] VIA VT6421A LPC memory ...
The Meson build files look really nice. Thanks for adding support for it. Would you mind pointing me to the part of the logic which takes care of all the special cases? I didn't see it at first glance, but I probably looked in the wrong place.
Is the Meson build intended to replace the current Makefile system or is it intended to handle some currently unsupported special cases only?
At the moment I'm using the meson port so I can include flashrom as a subproject to fwupd (as distros are not yet shipping libflashrom as a proper shared library) but 3mdeb is some way from being finished with libflashrom. I wondered if my work would be useful already to anyone else building flashrom on weird embedded architectures, or of it would be interesting to upstream with further work.
I'm always happy if people try to port flashrom to new architectures. In the past, supporting new architectures with MMIO-based interfaces usually led to a chase down the rabbit hole until we could find someone who knew the memory ordering rules and associated Linux kernel interfaces of the architecture well enough (thanks Segher!).
If you're aware of any architecture or platform or delivery mechanism where the current Makefile doesn't work, I'd appreciate a pointer so I can fix the current solution until we have a new solution working on all platforms.
The single commit which just adds 5 files can be found here: https://github.com/hughsie/flashrom/tree/wip/hughsie/meson
Comments welcome.
Correct me if I'm wrong, but it looks like the build logic in your current tree errors out if someone tries to build the internal programmer on non-x86 platforms. IIRC flashrom currently builds fine at least on MIPS (Loongson-2F internal programmer support).
The current Makefile supports the following (sometimes exotic) cases: - native build on Linux (different libpci versions need different compile options) - native build for Debian/KFreeBSD - native build on Windows - native build on Mac OS X - native builds on all the BSDs (Free, Open, Net, Dragonfly) - standalone build against libpayload - cross-builds on Linux for DOS - cross-builds on Linux for Windows - cross-builds on Linux for Mac OS X - static builds - and probably a bunch of others I forgot
Yes, the number of people completely understanding the Makefile is lower than we'd like. I'm all for cleaning this up if we can find a solution which works well enough on all supported platforms.
Thanks again for your work.
Regards, Carl-Daniel