Buildroot Developers Meeting, 4-5 February 2013, Brussels

What is Buildroot ?

Buildroot is a set of Makefiles and patches that makes it easy to generate a complete embedded Linux system. Buildroot can generate any or all of a cross-compilation toolchain, a root filesystem, a kernel image and a bootloader image. Buildroot is useful mainly for people working with small or embedded systems, using various CPU architectures (x86, ARM, MIPS, PowerPC, etc.) : it automates the building process of your embedded system and eases the cross-compilation process.

Thanks to our sponsor Google

We would like to thank Google, who will be providing the meeting location, with Internet connection, but also free lunch and refreshments for the meeting participants. Thanks Google!

It is worth noting that Google is sponsoring due to their usage of Buildroot to build embedded Linux systems for embedded devices used in the Google Fiber project. The source code of their modified Buildroot is available at [1].

Location and date

The Buildroot community is organizing a meeting on Monday February 4th 2013 and Tuesday Feburary 5th 2013, for Buildroot developers and contributors. This meeting will be a mixture of discussion and hacking session around the Buildroot project. This meeting takes place right after the FOSDEM, in order to make it easy for participants to attend both events.

Note that it is not mandatory to attend both days. It is expected that the first day will be mostly dedicated to discussion, while the second day will be mostly dedicated to hacking.

The meeting will take place in Google Brussels offices, located Chaussée d'Etterbeek 180, 1040 Brussels. See http://goo.gl/maps/ZVAGJ for a map of the area.

Wild idea: for VCS site methods where version is HEAD or a branch, BR checks every time if the upstream has changed. This is to track the development made by team mates: your own work is in a OVERRIDE_SRCDIR, other libraries/dependencies are in a VCS method and are automatically updated. Question: how to expose this feature to the user? Addition kconfig option per package? Additional variable in local.mk? Something else?

Wild idea: make it possible to configure some things per package, like optimisation/debug flags, static library, ... - this would require serious modification to Kconfig or a meta-kconfig.

Provide a (nightly|weekly)-built manual from master. (Yann)

Use kconfig-frontends ? (Yann)

Remove the wget et al config options (Arnout)

Google Summer of Code 2013 (Thomas)

Patchwork maintenance, how to deal with pending patches (Arnout)

Discussion

Copy target before creating images: the idea is to avoid the need for creating idempotent scripts in e.g. post-build script. It does make sense, because for the user it's a bit more difficult to make scripts idempotent. Also it can be a step for hiding the "target" directory. And it makes complete sense if we remove the "target" directory completely and copy from staging instead.

The compelling reason to make target a subset of staging is that it is much easier to do debugging: just "gdb staging/usr/bin/foo" and it will have debug symbols and the paths to the source files.

Single install commands: FOO_INSTALL_CMDS. They get executed twice, with DESTDIR set to the correct place (target or staging or host). The POST_XXX_INSTALL_HOOKS would still be executed separately. But this doesn't yet give us the situation that target and staging are the same, but target just has some stuff removed.

Take it one step at the time: start with FOO_INSTALL_CMDS, we can see how far we get.

Document that post-build script has to be idempotent (with an example).

There was a lot of discussion about using buildroot in practice in different contexts. Add to documentation a section of how to use buildroot in practice. Maybe in the form of one or more use case - but not too many because it would just confuse users. For instance, assume that proprietary patches are in-tree in package/companyname, not out-of-tree. The chapter would be called "Integration into a development workflow".

There is a consensus that buildroot should not be just an integration platform, but also usable in development. However, we should never sacrifice the simplicity, and integration has to remain the main focus. The out-of-tree package build is a good example, as well as the automatic fetching of VCS HEAD.

Add chapter to manual to explain the internals of buildroot. Not so much the existing implementation, but rather the design choices.

post-image script: good thing is that it can be included in a defconfig, so accept it. Post-image script (just like post-build script) will not run in fakeroot.

Stable releases: the consensus is that it is a lot of effort and nobody would use it.

Users and contributors: contributors are still increasing, number of users we don't really know but probably pretty high.

Threats:

The number of forks of buildroot. We're missing out on contributors, and if it doesn't work well we loose credibility. For instance, armadeus doesn't upstream anything (no kernel, u-boot, buildroot) - for them there is no hope. But for instance also RPi has a buildroot fork on github. Maybe it would help if we would have an official repository on github (github can be setup to automatically pull form the official repository). If we really want, we could pull patches from the repositories that we know about. A fork that just adds a defconfig and a few feature patches is not a big deal, on condition that they are kept up to date.

Flash sizes are increasing, so the size advantage of buildroot is not much of an advantage anymore. Compared to e.g. emdebian, there are two more advantages:

much more understandable what happens at boot time and what exactly is installed, there's no predefined policy;

you have a top-level integration of the entire rootfs+kernel+bootloader from the start;

easy to learn for someone not familiar with Debian or Linux distros or system administration.

Thomas would like to add testimonials and a list of users of buildroot to the website.

Next big directions for buildroot

SoC-specific libraries (OpenGL) are a pain: packages that use them need to somehow find them. We can use a virtual package mechanism like for jpeg (but then a bit different) and e.g. Qt5 depends on that virtual package.

Switching to ct-ng as the default toolchain backend has been in the plans for several years. But since it's not the default backend it isn't getting a lot of attention (example: for several months it was broken, libraries were not copied to the target, and it took a lot of time for somebody to notice).

Issue #1: passing subarch variants to crosstool-ng. Shouldn't be a big problem to solve, just a matter of work.

Issue #2: download integration. Crosstool-NG cannot tell Buildroot what it needs, so Buildroot can't download it, which breaks things like "make source" and "make external-deps". This requires a number of changes in Crosstool-NG: Crosstool-NG doesn't know the exact URL for each component, doesn't yet have a capability to list which tarballs are needed (similar to "external-deps"). It has the capability of doing the download only, but it requires configure and installing crosstool-NG. Which means that "make source" in Buildroot would need to build Crosstool-NG and all its dependencies (host-gawk, host-libtool, host-autoconf, host-automake). This problem requires more work at the Crosstool-NG level.

Issue #3: legal info integration.

Option 1: keep only external toolchain backend. Consensus is that this is not acceptable, Buildroot should still have a way of building toolchains on its own.

Option 2: work on the Crosstool-NG backend to fix all the integration issues, and use it as the default backend.

Option 3: improve the internal backend, and assume that we don't really need an integration with Crosstool-NG.

Conclusion: Yann gets time till 2013.05 to work on issue #2. If that is successful or is making good progress, we go for Option 2. If it is going nowhere, we go for Option 3 or option 1.

Handling of make xxx-menuconfig

The last proposal on the list was to store the xxx-config files in the output directory, and don't remove them with make clean. However, if you delete the output directory that will still be gone.

Instead, it can directly be saved to the configured place (e.g. boards/mycompany/myboard/xxx-config) instead of requiring an explicit 'make xxx-saveconfig' step. Potential problem: do we save a defconfig or a full config? Linux defconfig only exists since 2.6.26 or so and is sometimes buggy...

We can disallow linux-menuconfig in case the BR2_LINUX_USE_CUSTOM_CONFIG is not set, and issue a warning. Combine that with automatically saving and we have a pretty complete solution.

Conclusion: copy it back to the configured place, disallow xxx-menuconfig unless something is configured. We always save full config because defconfig is not always reliable.

Splitting package/Config.in into separate files for each menu is a good idea for several reasons:

In patches adding a package, it's obvious in which menu it is added

Scripts can automatically find out in which menu a package is, e.g. to generate the package list in the manual

Out of tree package build

It's mainly needed for the kernel

But it's also nice for the 600 other packages that support it out of the box.

Risk of breakage, but can easily be solved by setting SUPPORTS_OUT_OF_TREE to NO

Makes it slower for some large packages that don't support out-of-tree build, but also saves time for some others.

Conclusion: the series still needs some work, but we do like out-of-tree package builds.

Some .la files in the staging directory contain wrong information: paths to the build directory instead of the staging directory. Samuel proposes to remove the .la files. This needs some testing first, though.

Devel-on-target packages are not removed quite yet. But more packages can be marked as deprecated.

What to do with systemd/udev/eudev: we try to use the udev from systemd without systemd. Exactly how we don't know yet... There's a risk that udev becomes unusable without systemd, but Leonard Poettering promised this would not happen. After a quick look, it turns out that you always end up building systemd, which requires dbus, even if you need only udev. So it makes the systemd source tarball a bit unpractical to build a system that uses udev only, and doesn't need systemd. Probably an indication that we should have a look at eudev? How would this interact with the systemd selection? What about incompatibilities between udev and eudev?

Building a fully configured project: the question is: what is the workflow for creating a buildroot-based distribution which has a lot more than just the defconfig, and you don't want to fork the buildroot repository. Answer: fork the buildroot tree, but merge regularly.

Autobuilder status: Thomas will move the info to a database, and has some very basic webpages for accessing the database. He also dreams about running some tests in qemu - but we already have enough failures with the autobuilders as they are :-)

Remove the wget et al config options (Arnout): these options are indeed useless, especially because dependencies.sh looks for "git", not BR2_GIT. But in fact, the whole "Build options" menu could use some refactoring.

scratchbox2: may make life simpler to support cross-compiling. scratchbox2 does LD_PRELOAD magic to make sure that /usr/include and /usr/lib point into the sysroot instead of the host. It also runs foreign executables in qemu. However, Thomas (who used scratchbox before) was not impressed by it. It will probably also run into the kernel headers problems we had with cpanminus/qemu. Bottom line: it can be used if some package requires it, but in the end we will still have to solve cross-compilation issues.

Use kconfig-frontends: we would clone it into buildroot, just like we currently do. Advantage of current kconfig-frontends is that it has some possibilities for tweaking the config executable, so that we need less or no patches. Still it's a bit of work to integrate. One problem is that it now has a configure script, which checks for flex, bison, gperf, and we want to bypass this in buildroot. We will create our own Makefile (just like we do now) and we'll check in the files generated by flex, bison, gperf. Yann doesn't have a lot of time to work on this.

GSoC: student works 3 months full-time on a project. Google has to accept it, so it has to be somehow innovative and end up with a product. Core infrastructure work is probably not a good idea, because it's too difficult. Cleaning up and merging the blackfin fork or solving the autobuilder failures may not be a sufficiently well-defined project. Also there is some work for us: interviewing the students, mentoring, ... Thomas will write one or two topics. E.g.: incorporate blackfin support; improvements to test infrastructure.

We iterated on the AVAILABLE problem once more, and concluded once more that none of the solutions is fully satisfying. The extra AVAILABLE options don't solve the comments - and we really want the comments. Replacing the comments with some generic statement that the required toolchain options are not available is not enough, because it's almost impossible to see which toolchain options you need. The best compromise is to have a script that checks if the dependencies and the comments are inconsistent, but it's not clear how easy it would be to create such a script - perhaps with the [[[2]] python-kconfig] it's doable. The script could even automatically modify the Config.in in a later stage.

Patchwork: at FOSDEM, Wolfram Sang mentioned some scripts that he uses to integrate patchwork into his git workflow. Peter is already using that to automate getting patches from patchwork and updating the patch status when it is pushed.

Flags in external toolchain wrapper. The source of this discussion is the Cavium toolchain which requires an additional linker option to link correctly. Note that this is only about compile/link flags that are strictly needed for compiling for the right target, so typically things like -mfpu. The conclusion is that we want:

For toolchains built by buildroot (internal, ct-ng), the toolchain configuration itself should already have the right options.

For external toolchains downloaded by buildroot, buildroot should add the correct flags in the toolchain wrapper to do the right thing.

For custom external toolchains, there should be a free-text config option that is coded into the toolchain wrapper.

The BR2_TARGET_OPTIMIZATION option should be renamed to something more sensible, and only be used in TARGET_CFLAGS (not in the wrapper).

Action point list

post-build script documentation (Yann E. MORIN)

merge the staging and target install steps, and have all packages installed to both the staging and target directories

For the patches stored in the package directory, if package/<pkg>/<version>/ does exist, apply package/<pkg>/<version>/*.patch, otherwise, apply package/<pkg>/*.patch

For the patches stored in the global patches directory, if $(GLOBAL_PATCH_DIR)/<pkg>/<version>/ does exist, apply $(GLOBAL_PATCH_DIR)/<pkg>/<version>/*.patch, otherwise, apply $(GLOBAL_PATCH_DIR)/<pkg>/*.patch