On Thu, 3 Jan 2019 at 21:05, Carl-Daniel Hailfinger <[email protected]> wrote: > 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).
Right, I never had much luck with autotools either. > so eliminating all warnings is not going to be possible with > all gcc versions. Agreed. > but because a sufficiently recent CMake was not available on all > supported platforms, most notably old RHEL versions. >From my point of view (as a Red Hat employee) the earliest RHEL I need to care about for new features is 8, and in exceptional cases 7. Unfortunately (or fortunately, depending on how you look at it) fwupd rebases into RHEL 7 are oft-requested and so I need to make sure the latest fwupd builds in RHEL 7, which for the 7.6 release meant preparing a meson package that could work in this environment. But see below... > 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. I assume you mean stuff like https://github.com/hughsie/flashrom/commit/b8e57e804d121097f7634b68a8c1d7c5bae90f46#diff-969b60ad3d206fd45c208e266ccfed38R274 ? -- note: I didn't copy all the logic for non-Linux systems, e.g. DOS or MinGW. Partially because I'd have no way to test the build, but mostly because I didn't want to spent too much time on it if the flashrom maintainers thought it was a hugely bad idea and would never be upstreamed. > Is the Meson build intended to replace the current Makefile system or is > it intended to handle some currently unsupported special cases only? I don't think it has to replace the existing system. The existing Makefile has years of being battle-tested in all kinds of odd setups and is probably good enough for most people just installing everything to /usr. If you're using something like flatpak that's using prefixes or using flashrom as a subproject to another project then you're going to massively appreciate meson. The downside is that adding extra source files means you have to edit two build files. From someone that's done this for several projects it does get tiresome, although it does give everyone a large "grace" period to adjust to the new world order before removing any other build system. My gut instinct is that flashrom should continue to have Makefile as the "primary" build system that blocks CI and let those that want to use meson send patches to keep the meson.build up to date. It also means we don't need to support and test every single esoteric OS in the meson build. > I'm always happy if people try to port flashrom to new architectures. I actually ended up disabling flashrom support for fwupd on things like ppc64le -- on the logic you're probably not going to be using flashrom to perform updates on such systems... > 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. That was some debugging that I accidentally left in. If you think it's worthwhile I can spend some more time on the meson branch and fix up things like this. >- standalone build against libpayload I didn't really "get" libpayload -- can somebody describe what it is? Thanks. > - standalone build against libpayload > - cross-builds on Linux for DOS > - cross-builds on Linux for Windows > - cross-builds on Linux for Mac OS X Cross builds are a lot easier with meson, although I've not actually tested it with flashrom. > - static builds This works. Richard. _______________________________________________ flashrom mailing list -- [email protected] To unsubscribe send an email to [email protected]
