Some comments from a packager and experience with switching to cmake, some of it ok, some of it bad. I'm trimming stuff I don't have any comments on as I think you have this mostly right.
Thomas Heijligen <s...@posteo.de> writes: > ## Platforms to support > * Systems > * Linux (Distros / ChromeOS) Long-Term Stable is a real issue. It's not really reasonable for people to expect to build new flashrom with ancient tools, on a system where they have chosen to run old code to get some kind of stability. Yet people routinely demand that they be able to build the latest release of Foo using an LTS with compiler, autoconf, cmake and the like from 5 years ago. They want new Foo, but suggesting they get non-crufty tools and they act like upstream is being unreasonable because their LTS is "supported". My respones is "well, tell RHEL/Ubuntu to do it for you and stop demanding I do it". > * SunOS / Solaris / the current version of it There are two worlds: Oracle Solaris and illumos (OmniOS, OpenIndiana, and more). Probably doesn't need specific code for both, but good to be aware. > * Architectures > * X86 > * ARM > * MIPS > * POWER > x86 supports port I/O (mostly relevant to PCI), others may through > MMIO emulation I guess that's an interesting question. I'm not clear on the full set of interfaces for reading/writing. But really the code should be portable to any reasonable CPU. x86, arm, mips, and ppc are really pairs of CPU architectures, each of which has a 32-bit and a 64-bit variant. And it's a pretty short list; NetBSD also runs on sparc, sparc64, m68k, and less sensible for flashrom, vax, alpha, ia64, and hppa. And, RISC-V is coming and I expect it to appear whereever arm64 does in a few years. In requirements, you left out (but I know you are thinking of cross): cross compilation Almost entirely, switch code on/off by feature tests, and attempt to drive the number of "#ifdef FooOS" to zero. It's not doable entirely, but autoconf got this right and a lot of things that claim they are better do not. > * Write documentation > * Build instructions for all platforms Aside from windows, they really should not be different. > ## Open questions > * System requirements > * How long should we support systems / libraries? > * As long as they have vendor support That's very messy. On one hand if vendors (== "os maintainers") drop support early, it's good to go back slightly further. On the other, if someone decides to freeze code in 2020 and maintain it with *security patches only* for 10 years, then I think a reasonable response is "if you want to run code from 2020 with only security patches, good luck - the license gives you the freedom to do that, but it's not our obligation to do work to make that be easy". Note that such people are welcome to keep running the flashrom version from 2020; that is after all what they chose to do. Yes, I sound cranky, but the crankiness comes from maintaining unison. > * What should be the minimum required version of meson? > * The version of the oldest supported system. Again, same issue. > * Build dependencies > * Can we fetch dependencies like cmocka? This makes building for > some systems easier No, you can't fetch anything at build time. Packaging systems view that as a bug. It means you can't build on a machine not on the internet. Yes, I have built lots of packages on a disconnected machine after fetching their releaes tarballs and transferring on CDROM, and it almost entirely works. So options are: if you want to depend on something, list in in the README and demand that the user have it installed already. If it doesn't already exist as a package in most packaging systems, that's a clue you shouldn't use it. vendor it in. But you really shouldn't do this, because then when there is a security release of that included code, you really need to have a new micro very fast, and I'll pick 7 days out of a hat. > * Shared libflashrom > * How to handle versioning? shared library major/minor is pretty well established (major bump on ABI break, minor bump on ABI addition, and try really hard not to break the ABI). I'm not sure what the question is. > ## Sequence for switching the primary build system > * Meson is feature equivalente with the Makefile > * Switch to meson as default build system, update the documentation > * Make a release with meson as the primary build system, keep the > Makefile for legacy compatible. > * Drop the Makefile > * Drop dead code from Makefile only based option Understand that packagers will need to put in work to switch, they aren't usually paid 40h/week to package, and they don't think flashrom is the most important thing in the world. So what you said means that they have the time between the release with meson documented as primary and the release w/o Makefile. If meson behaves as well as meson proponents say (which given what I've heard about the plan seems likely), that will be only a few hours or less. As a nit there should be at least 2 months between "release where meson is primary and no significant meson problems are reported" and "release w/o Makefile". > 5. Define what testing means. Should we run flashrom or flash > something? How do we check that meson supports the system? > 1. Build and run unit tests. > 2. Run the binary to see that it works > 3. Great thing would be to use one (or more :)) programmer. Maybe > just dummy? I think you need to at least read a ROM and compare, and really flash an update. But that's only when other tests are all happy and less often. Hope this helps.
signature.asc
Description: PGP signature
_______________________________________________ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
