Difference between revisions of "Buildroot"

From eLinux.org
Jump to: navigation, search
(release tarball contains documentation since 2012.02)
(Documentation)
(16 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Buildroot is a nice, simple, and efficient embedded Linux build system. [http://www.buildroot.org Buildroot main page]
+
Buildroot is a nice, simple, and efficient embedded Linux build system.
 +
 
 +
== Important links ==
 +
 
 +
* [http://www.buildroot.org Buildroot main page]
 +
* [http://bugs.uclibc.org Bug tracker]
 +
* [http://autobuild.buildroot.org Autobuilders results]
 +
* [http://patchwork.ozlabs.org/project/buildroot/list/ Project patchwork]
 +
* [[Buildroot:DeveloperDaysELCE2012 | Buildroot Developers Days]], 3-4 November 2012, Barcelona Spain, before ELCE.
 +
 
 +
==List of forks==
 +
 
 +
* [https://github.com/nezticle/RaspberryPi-BuildRoot]. A Rasberry-Pi related fork.
  
 
==Todo list==
 
==Todo list==
Line 5: Line 17:
 
This is a list of improvements that we would like to see in buildroot.  Feel free to add suggestions here.  If you're working on one of these items, put your name and the date behind it, to avoid duplicate work.
 
This is a list of improvements that we would like to see in buildroot.  Feel free to add suggestions here.  If you're working on one of these items, put your name and the date behind it, to avoid duplicate work.
  
 +
=== Packages ===
 +
 +
* Create a package for ''qt5'' (separate from qt4) -- In progress, by Thomas Petazzoni.
 +
 +
=== Documentation ===
  
 
* [[Buildroot how to contribute | Document how to contribute]] (patches to list instead of bugzilla, SOB, formatting rules, acked-by and tested-by, how often to repost, what to expect, CC's, ...) [[Buildroot how to contribute | basic guide]]  
 
* [[Buildroot how to contribute | Document how to contribute]] (patches to list instead of bugzilla, SOB, formatting rules, acked-by and tested-by, how often to repost, what to expect, CC's, ...) [[Buildroot how to contribute | basic guide]]  
 
* Document how a package patch should be formatted (Comment, SOB, file naming rules, ...) + send upstream + CC sendpatches
 
* Document how a package patch should be formatted (Comment, SOB, file naming rules, ...) + send upstream + CC sendpatches
 +
* In documentation, explain how to report a bug
 +
 +
=== Build/release infrastructure ===
 +
 
* Peter sets up a planet on whatever server and links to it from buildroot website
 
* Peter sets up a planet on whatever server and links to it from buildroot website
* Peter sets up a cgi script on the website where test results can be POST-ed
 
 
* Peter adds a script to the website to generate on-line documentation from asciidoc
 
* Peter adds a script to the website to generate on-line documentation from asciidoc
* Peter contacts ozlabs.org to request hosting a patchwork for buildroot
+
 
* Finalize legal-info
+
=== Core Buildroot infrastructure ===
 +
 
 
* Clean up infrastructure for applying patches: modify apply-patches script to support new naming scheme, migrate existing patches, remove architecture-specific patch support
 
* Clean up infrastructure for applying patches: modify apply-patches script to support new naming scheme, migrate existing patches, remove architecture-specific patch support
* In documentation, explain how to report a bug
 
 
* Add rsync to target-finalize, document this as the preferred method of customizing the target rootfs
 
* Add rsync to target-finalize, document this as the preferred method of customizing the target rootfs
* The CMake toolchain file should be moved somewhere into host/ to be part of the SDK, maybe host/usr/share/cmake or host/usr/share/buildroot.
 
 
* It would be nice to add a br-configure script in host/usr/bin for autotools-based packages.  Run ...BUILDROOTSDK/usr/bin/br-configure --enable-foo --disable-bar, and the br-configure script would call the ./configure script in the current directory passing all the right options (--host, and all environment variables CC, LD, AS, AR and such).
 
* It would be nice to add a br-configure script in host/usr/bin for autotools-based packages.  Run ...BUILDROOTSDK/usr/bin/br-configure --enable-foo --disable-bar, and the br-configure script would call the ./configure script in the current directory passing all the right options (--host, and all environment variables CC, LD, AS, AR and such).
* (done) Add the generated manual to the release tarball in the ''release'' target
 
  
Here is what needs to be done to make the HOST-directory a relocatable SDK:
+
* Make the HOST-directory a relocatable SDK:
* Make sure that all binaries and libraries built for the host are built with a rpath pointing to host/usr/lib. Normally, this should already be the case, but it's worth checking.
+
** Make sure that all binaries and libraries built for the host are built with a rpath pointing to host/usr/lib. Normally, this should already be the case, but it's worth checking.
* Change the rpath value to $ORIGIN/../lib instead of the current absolute path $(O)/host/usr/lib.
+
** Change the rpath value to $ORIGIN/../lib instead of the current absolute path $(O)/host/usr/lib.
* Modify the compiler wrapper program of external toolchains so that instead of using a fixed location for the compiler tools, it deduces their location in a relative manner from its current location.
+
** Modify the compiler wrapper program of external toolchains so that instead of using a fixed location for the compiler tools, it deduces their location in a relative manner from its current location.
* Modify/patch pkg-config so that instead of having a fixed location for the PKG_CONFIG_PATH and PKG_CONFIG_SYSROOT_DIR, those are deduced from the location of the pkg-config binary. This will allow a pkg-config binary that has been moved to still operate properly, without having to set any environment variable.
+
** Modify/patch pkg-config so that instead of having a fixed location for the PKG_CONFIG_PATH and PKG_CONFIG_SYSROOT_DIR, those are deduced from the location of the pkg-config binary. This will allow a pkg-config binary that has been moved to still operate properly, without having to set any environment variable.
* Write a shell script, installed in host/usr/bin, which would mungle the libtool .la files, the qmake.conf file and the CMake toolchain file to set the correct path. This script reads a file (can be host/usr/share/buildroot/location) which contains the original location of the SDK. This allows the script to do the right modifications on all the libtool, qmake.conf and cmake files. Once this is done, the script changes the host/usr/share/buildroot/location file so that it contains the new location.
+
** Write a shell script, installed in host/usr/bin, which would mungle the libtool .la files, the qmake.conf file and the CMake toolchain file to set the correct path. This script reads a file (can be host/usr/share/buildroot/location) which contains the original location of the SDK. This allows the script to do the right modifications on all the libtool, qmake.conf and cmake files. Once this is done, the script changes the host/usr/share/buildroot/location file so that it contains the new location.
* Modify the external toolchain wrapper so that it bails out and warns the user if the directory it is executed in doesn't match the location of host/usr/share/buildroot/location. We haven't discussed how this could work with internal and crosstool-NG toolchains, though.
+
** Modify the external toolchain wrapper so that it bails out and warns the user if the directory it is executed in doesn't match the location of host/usr/share/buildroot/location. We haven't discussed how this could work with internal and crosstool-NG toolchains, though.
 +
 
 +
=== TODO items under discussion ===
  
 
Here are some nice-to-have's for which it is not entirely clear if and how they could be implemented:
 
Here are some nice-to-have's for which it is not entirely clear if and how they could be implemented:
 +
 
* Out-of-tree builds, which allows the package source to be shared between different output directories and between host and target compiles.
 
* Out-of-tree builds, which allows the package source to be shared between different output directories and between host and target compiles.
 
* It would be nice if you could run a buildroot command that prepares a local copy of a package's source, and allows you to generate patches for it later. This could use git or quilt to keep track of the patches.
 
* It would be nice if you could run a buildroot command that prepares a local copy of a package's source, and allows you to generate patches for it later. This could use git or quilt to keep track of the patches.

Revision as of 19:07, 9 February 2013

Buildroot is a nice, simple, and efficient embedded Linux build system.

Important links

List of forks

  • [1]. A Rasberry-Pi related fork.

Todo list

This is a list of improvements that we would like to see in buildroot. Feel free to add suggestions here. If you're working on one of these items, put your name and the date behind it, to avoid duplicate work.

Packages

  • Create a package for qt5 (separate from qt4) -- In progress, by Thomas Petazzoni.

Documentation

  • Document how to contribute (patches to list instead of bugzilla, SOB, formatting rules, acked-by and tested-by, how often to repost, what to expect, CC's, ...) basic guide
  • Document how a package patch should be formatted (Comment, SOB, file naming rules, ...) + send upstream + CC sendpatches
  • In documentation, explain how to report a bug

Build/release infrastructure

  • Peter sets up a planet on whatever server and links to it from buildroot website
  • Peter adds a script to the website to generate on-line documentation from asciidoc

Core Buildroot infrastructure

  • Clean up infrastructure for applying patches: modify apply-patches script to support new naming scheme, migrate existing patches, remove architecture-specific patch support
  • Add rsync to target-finalize, document this as the preferred method of customizing the target rootfs
  • It would be nice to add a br-configure script in host/usr/bin for autotools-based packages. Run ...BUILDROOTSDK/usr/bin/br-configure --enable-foo --disable-bar, and the br-configure script would call the ./configure script in the current directory passing all the right options (--host, and all environment variables CC, LD, AS, AR and such).
  • Make the HOST-directory a relocatable SDK:
    • Make sure that all binaries and libraries built for the host are built with a rpath pointing to host/usr/lib. Normally, this should already be the case, but it's worth checking.
    • Change the rpath value to $ORIGIN/../lib instead of the current absolute path $(O)/host/usr/lib.
    • Modify the compiler wrapper program of external toolchains so that instead of using a fixed location for the compiler tools, it deduces their location in a relative manner from its current location.
    • Modify/patch pkg-config so that instead of having a fixed location for the PKG_CONFIG_PATH and PKG_CONFIG_SYSROOT_DIR, those are deduced from the location of the pkg-config binary. This will allow a pkg-config binary that has been moved to still operate properly, without having to set any environment variable.
    • Write a shell script, installed in host/usr/bin, which would mungle the libtool .la files, the qmake.conf file and the CMake toolchain file to set the correct path. This script reads a file (can be host/usr/share/buildroot/location) which contains the original location of the SDK. This allows the script to do the right modifications on all the libtool, qmake.conf and cmake files. Once this is done, the script changes the host/usr/share/buildroot/location file so that it contains the new location.
    • Modify the external toolchain wrapper so that it bails out and warns the user if the directory it is executed in doesn't match the location of host/usr/share/buildroot/location. We haven't discussed how this could work with internal and crosstool-NG toolchains, though.

TODO items under discussion

Here are some nice-to-have's for which it is not entirely clear if and how they could be implemented:

  • Out-of-tree builds, which allows the package source to be shared between different output directories and between host and target compiles.
  • It would be nice if you could run a buildroot command that prepares a local copy of a package's source, and allows you to generate patches for it later. This could use git or quilt to keep track of the patches.
  • It would be nice if there was a make target to reinstall everything to the target (i.e. remove all the target-installed stamps, remove the root stamp, maybe remove the target too). However, what is missing is the copying of the toolchain support files (libc.so etc.). It's not obvious that this can be done in a reliable way.
  • It would be nice if there was some common infrastructure to combine the images into one final flash or SD card or whatever image. However, it is probably difficult to find the commonality of all the different use cases. And we don't even see all these use cases.
  • SoC-specific architectures: it would be nice if the user could select e.g. OMAP3 instead of Cortex-A8. It's a bit unclear what granularity would be needed here (OMAP? OMAP3? OMAP3530?). Also, it seems to be too much maintenance work to support all that, and the list of SoCs or SoC families could grow very long.
  • The uninstall targets are pretty useless because they don't really work. Should we remove support for uninstall?
  • It would be nice to have support for neon, vfp, thumb2, ... Tricky for external compilers, because we must know if it matches the options we want to give it.