so it will not select +Package A+.
* Since +Package B+ is selected but +Package A+ is not, this violates
- the dependency of +Package B+ on +Package A+. Therefore, in such a
+ the dependency of +Package B+ on +Package A+. Therefore, in such a
situation, the transitive dependency has to be added explicitly:
--------------------------
compilation and installation of the package. This
infrastructure must be used for all packages that do not use the
autotools as their build system. In the future, other specialized
- infrastructures might be written for other build systems. We cover
+ infrastructures might be written for other build systems. We cover
them through in a xref:generic-package-tutorial[tutorial] and a
xref:generic-package-reference[reference].
==== +generic-package+ reference
There are two variants of the generic target. The +generic-package+ macro is
-used for packages to be cross-compiled for the target. The
+used for packages to be cross-compiled for the target. The
+host-generic-package+ macro is used for host packages, natively compiled
-for the host. It is possible to call both of them in a single +.mk+
+for the host. It is possible to call both of them in a single +.mk+
file: once to create the rules to generate a target
package and once to create the rules to generate a host package:
is unnecessary. When +HOST_LIBFOO_SITE_METHOD+ is not specified, it
defaults to the value of +LIBFOO_SITE_METHOD+. +
The possible values of +LIBFOO_SITE_METHOD+ are:
- ** +wget+ for normal FTP/HTTP downloads of tarballs. Used by
+ ** +wget+ for normal FTP/HTTP downloads of tarballs. Used by
default when +LIBFOO_SITE+ begins with +http://+, +https://+ or
+ftp://+.
- ** +scp+ for downloads of tarballs over SSH with scp. Used by
+ ** +scp+ for downloads of tarballs over SSH with scp. Used by
default when +LIBFOO_SITE+ begins with +scp://+.
** +svn+ for retrieving source code from a Subversion repository.
- Used by default when +LIBFOO_SITE+ begins with +svn://+. When a
+ Used by default when +LIBFOO_SITE+ begins with +svn://+. When a
+http://+ Subversion repository URL is specified in
+LIBFOO_SITE+, one 'must' specify +LIBFOO_SITE_METHOD=svn+.
Buildroot performs a checkout which is preserved as a tarball in
+LIBFOO_SITE+ 'must' contain the source URL as well as the remote
repository directory. The module is the package name.
+LIBFOO_VERSION+ is 'mandatory' and 'must' be a timestamp.
- ** +git+ for retrieving source code from a Git repository. Used by
+ ** +git+ for retrieving source code from a Git repository. Used by
default when +LIBFOO_SITE+ begins with +git://+. The downloaded
source code is cached as with the +svn+
method.
** +bzr+ for retrieving source code from a Bazaar repository. Used
by default when +LIBFOO_SITE+ begins with +bzr://+. The
downloaded source code is cached as with the +svn+ method.
- ** +file+ for a local tarball. One should use this when
+ ** +file+ for a local tarball. One should use this when
+LIBFOO_SITE+ specifies a package tarball as a local filename.
Useful for software that isn't available publicly or in version
control.
- ** +local+ for a local source code directory. One should use this
+ ** +local+ for a local source code directory. One should use this
when +LIBFOO_SITE+ specifies a local directory path containing
- the package source code. Buildroot copies the contents of the
+ the package source code. Buildroot copies the contents of the
source directory into the package's build directory.
* +LIBFOO_DEPENDENCIES+ lists the dependencies (in terms of package
* +HOST_PYTHON_FOO_NEEDS_HOST_PYTHON+, to define the host python
interpreter. The usage of this variable is limited to host
- packages. The two supported value are +python2+ and +python3+. It
+ packages. The two supported value are +python2+ and +python3+. It
will ensures the right host python package is available and will
invoke it for the build. If some build steps are overloaded, the
right python interpreter must be explicitly called in the commands.
uClibc::
+
-Configuration of uClibc is done in the same way as for BusyBox. The
+Configuration of uClibc is done in the same way as for BusyBox. The
configuration variable to specify an existing configuration file is
+BR2_UCLIBC_CONFIG+. The command to make subsequent changes is +make
uclibc-menuconfig+.
information.
When added to the individual commits, this changelog is added when
-editing the commit message. Below the +Signed-off-by+ section, add
+editing the commit message. Below the +Signed-off-by+ section, add
+---+ and your changelog.
Although the changelog will be visible for the reviewers in the mail
+board/<company>/<boardname>/foo.config+.
Make sure that you create a configuration file 'before' changing
-the +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE+ etc. options. Otherwise,
+the +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE+ etc. options. Otherwise,
Buildroot will try to access this config file, which doesn't exist
yet, and will fail. You can create the configuration file by running
+make linux-menuconfig+ etc.
configuration files easier.
* +make linux-update-defconfig+ saves the linux configuration to the
- path specified by +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE+. It
- simplifies the config file by removing default values. However,
- this only works with kernels starting from 2.6.33. For earlier
+ path specified by +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE+. It
+ simplifies the config file by removing default values. However,
+ this only works with kernels starting from 2.6.33. For earlier
kernels, use +make linux-update-config+.
* +make busybox-update-config+ saves the busybox configuration to the
path specified by +BR2_PACKAGE_BUSYBOX_CONFIG+.
Sometimes it is needed to set specific permissions or ownership on files
or device nodes. For example, certain files may need to be owned by
-root. Since the post-build scripts are not run as root, you cannot do
+root. Since the post-build scripts are not run as root, you cannot do
such changes from there unless you use an explicit fakeroot from the
post-build script.
In general, any new package should be added directly in the +package+
directory and submitted to the Buildroot upstream project. How to add
packages to Buildroot in general is explained in full detail in
-xref:adding-packages[] and will not be repeated here. However, your
+xref:adding-packages[] and will not be repeated here. However, your
project may need some proprietary packages that cannot be upstreamed.
This section will explain how you can keep such project-specific
packages in a project-specific directory.
Set +BR2_ROOTFS_OVERLAY+
to +board/<manufacturer>/<boardname>/rootfs-overlay+.
1. Create a post-build script
- +board/<manufacturer>/<boardname>/post_build.sh+. Set
+ +board/<manufacturer>/<boardname>/post_build.sh+. Set
+BR2_ROOTFS_POST_BUILD_SCRIPT+ to
+board/<manufacturer>/<boardname>/post_build.sh+
1. If additional setuid permissions have to be set or device nodes have
If you maintain several Buildroot trees, it might be better to have a
shared download location. This can be achieved by pointing the
-+BR2_DL_DIR+ environment variable to a directory. If this is
++BR2_DL_DIR+ environment variable to a directory. If this is
set, then the value of +BR2_DL_DIR+ in the Buildroot configuration is
overridden. The following line should be added to +<~/.bashrc>+.
+/dev/+ (Buildroot can't create them because Buildroot doesn't run
as root and doesn't want to run as root). Also, it doesn't have the correct
permissions (e.g. setuid for the busybox binary). Therefore, this directory
- *should not be used on your target*. Instead, you should use one of
+ *should not be used on your target*. Instead, you should use one of
the images built in the +images/+ directory. If you need an
extracted image of the root filesystem for booting over NFS, then
use the tarball image generated in +images/+ and extract it as
It is also possible to generate the Buildroot toolchain in a directory
other than +output/host+ by using the +Build options -> Host dir+
-option. This could be useful if the toolchain must be shared with
+option. This could be useful if the toolchain must be shared with
other users.