Hi,
Here an overview about the One Build System Project for flashrom. I'm sorry for the extreme late anouncement of the passed meeting. We had some diffent ideas about it. The next one will be anounced in a prper advanced and with a survay to choose a time.
Please feel free to contribute, take over a task, start a discousion, comment in the document or reply to this mail.
https://docs.google.com/document/d/1TVso_VbrLEbGc7BNrYxqlrP8jMxB23TuMqEI3PnC... ----------------------------------------------------------------------- # Flashrom One Build System Working Group [Draft]
## Goal Make meson the only build system for flashrom. Support all currently supported platforms.
## Abstract Modify, extend, rewrite the meson based build system to accommodate all requirements from flashrom. Rearrange the code for a best fit with the meson build system. Adapt the Makefile to these changes to have it working until its end.
## Notify me Add me to all to all build system related patches. (Or only to Make / Meson related one.) * Thomas Heijligen src@posteo.de
## Platforms to support * Systems * Linux (Distros / ChromeOS) * BSD (Free, Net, Open, Dragonfly) * MacOS * Android? * SunOS / Solaris / the current version of it * Debian kFreeBSD * GNU / HURD * Windows (mingw cross / cygwin) * DOS (djgpp cross from Linux) * libpayload (cross from Linux) * Architectures * X86 * ARM * MIPS * POWER x86 supports port I/O (mostly relevant to PCI), others may through MMIO emulation
## Tasks * Update the meson programmer selection to a positive list (see meson snippets) * Clean up the meson file and use best practices for meson * PoC: crosscompile “Hello World” for dos / djgpp with meson (with pci support) * PoC: crosscompile “Hello World” for libpayload with meson (with pci support) * Identify the active programmer in the man page * Add a note for each programmer that is not active in the build * Integrate getopt for dos based builds * Write documentation * Build instructions for all platforms * Design of meson.build * Reason for minimal meson version * How to add programmer * Sync compile options (WIP https://review.coreboot.org/c/flashrom/+/58561) * Create directories for platform abstraction, programmer, include files (https://review.coreboot.org/c/flashrom/+/62899)
## Open questions * System requirements * How long should we support systems / libraries? * As long as they have vendor support * What should be the minimum required version of meson? * The version of the oldest supported system. * MacOS and DirectHW * What is the current status? * What is useful to support? * Can we integrate it into flashrom? * How to test it? * Internal programmer * Should a programmer call / access another programmer? * Can we split the internal programmer into smaller units (x86_bios, mips_longson, xyz_superio, linux_mtd) and use internal as a keyword to select one of those? * Would that make it easier to build and modify? * Build dependencies * Can we fetch dependencies like cmocka? This makes building for some systems easier * Unit tests * Can we build the cmoka test on top of libflashrom.a? * Can this replace self tests? * Meson feature options * Build the shared library as feature * Build the classic_cli as feature * Can be easily deselectet if not needed of not supported (libpayload) * Build the tests as feature * Build man-pages as feature * Build ich_descriptor_tool as feature * Shared libflashrom * How to handle versioning?
## 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
## meson snippets - Ideas | option('programmer', type : 'array', choices : ['auto' 'all' 'group_pci' 'group_usb' 'ch341a_spi' ‘drkaiser’]) * auto selects all programmer available on the platform if the dependencies are found * all selects all programmer available on the platform, failing id a dependency is not found * group_* selects all programmer in this group, fails if the system does not support the group or a dependency is not found * <programmer name> selects this programmer, fails if not available on system or missing dependency
| libusb1 = dependency(...) | libusb1_systems = [ ‘linux’ ‘freebsd’ ‘windows’ ‘mac’ … ] | libpci = dependency(...) | libpci_systems = [...] # systems where libpci is available | port_io = declare_dependency(...) # files needed for port I/O support | programmer = { | 'ch341a_spi' { | 'system' = libusb1_systems, | 'srcs' = [ 'ch341a_spi.c' 'usbdev.c' ], | 'flags' = [ 'CONFIG_CH341A_SPI=1'], | 'deps' = [ libusb1], | # 'active' = true / false # selected on runtime | }, | ‘drkaiser’ = { | ‘Systems’ = libpci_systems, | ‘arch’ = [ ‘x86’ ‘amd64’ ], | ‘srcs’ = [ ‘drkaiser.c’ ], | ‘flags’ = [ ‘-DCONFIG_DRKAISER=1’ ], | ‘deps’ = [ ‘libpci’ ‘port_io’ ], | # 'active' = true / false # selected on runtime | }, | } * The programmer struct defines each programmer with its associated things * A for loop iterates through the set and adds ‘active’ = true / false to each programmer depending if it should be build or not * This set can be used to select source files, flags, dependencies, build tests, documentation, … * Use declare_dependency() for internal platform support like x86_msr or serial.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
## Meeting Notes Meeting on Apr 6. 9:30 + 10:30 UTC+0 https://meet.google.com/sag-dyik-bbr Attendees: Peter, Nico, Thomas, Felix, Carl-Daniel, Anastasia 1. Clean up meson so that it doesn’t look like a copy of makefile. Make it easier and more readable. 1. TODO: See meson snippets 2. Internal programmer is special, it has different options for different platform. Hard to implement positive lists 3. Internal can be x86 or linux_mtd, so maybe there can be meta- internal which selects the one which is needed 4. TODO: Internal split? Needs research. Can be done in parallel with prototype of cross-compiling. Ask on dev meeting 5. New feature flag to support port I/O 6. Have proper set of meson options to work with. We have no versioning on libflashrom. API is stable but is not defined as stable. 2. What are the missing features in meson? 1. Make a list of system that we want to support. See systems to support 1. We don’t need to support macOS in the beginning but maybe add later 2. DirectHW ? 3. TODO: Can we ask on mailing list about two above, does it work? Add Stefan Reinauer to the email 2. Check meson can support all of those systems 1. TODO: Prototype for crosscompiling djgpp/dos 2. TODO: Prototype for crosscompiling with libpayload 3. TODO: Sync compile options (WIP https://review.coreboot.org/c/flashrom/+/58561 ) 4. Figure out who can test for each supported system. Not only build , but also test. 1. Collect info who has which hardware and is willing to test 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? 6. Add meson to documentation 7. Have one release with both meson and makefile, when everything is supported in meson 1. Maybe one beta release so that people can try 2. Have both meson and makefile on the readme 8. After that we can say that meson is the primary build system, and update all the documentation. 9. Start dropping makefile 10. Can the man page show what is enabled in specific build? 1. Can be in parallel 11. For future: Testing at least one hardware access programmer 12. Is libflashrom used by the flashrom binary or is it built into the flashrom binary? How about we build both on user systems? So the flashrom binary would be just the cli application.