How to Modify the Source of Buildroot Packages for Package Development

How to modify the source of Buildroot packages for package development?

Please read the Buildroot manual about the <pkg>_OVERRIDE_SRCDIR functionality. It does exactly what you are looking for.

How to use buildroot with custom changes in packages

Two options:

• For quick tests, modify the source code in output/build/<pkg>-<version>/, and run make <pkg>-rebuild to force the rebuild of that package. Note that output/build/<pkg>-<version>/ folders are lost when doing a make clean in Buildroot, so this is only good for some quick debugging/investigation.

• For actual development on the source code, I would suggest to use the <pkg>_OVERRIDE_SRCDIR mechanism. Create a local.mk file at the root of the Buildroot tree. In this file, put FOO_OVERRIDE_SRCDIR = $(HOME)/foo. From now on, Buildroot will no longer download/extract/patch the foo package, but instead will instead rsync the source code from $(HOME)/foo into the package build directory. Running make foo-rebuild will re-run rsync and restart the build of this package. This means you can change the source code in $(HOME)/foo and very quickly rebuild the package with those changes. See also slide 269 and following in https://bootlin.com/doc/training/buildroot/buildroot-slides.pdf.

What is the proper method to modify the autotools options of a Buildroot source package using BR2_EXTERNAL?

It would appear that there is no satisfactory way to accomplish this. After going through the make process in more detail, I find that the top level defconfig BR2_ options override the individual package options (such as, in my case, the presence or absence of BR2_STATIC_LIBS).

Update project-specific packages in buildroot

Buildroot will not svn update your sources. The reason for this, as well as the best solution to your needs, are described in section "Using Buildroot during development" of the Buildroot user manual.

The reason: Buildroot's downloads are meant to be constant: re-downloading the same package at the same <PKG>_VERSION is supposed to download exactly the same source code. This is normal when you use it as a build system, not when using it during development (which is what you ask for).

Solution 1: use the <PKG>_OVERRIDE_SRCDIR feature. Using it you can checkout all the packages you are developing in a separate directory, managed with svn, git or whatever you want. Buildroot will never touch your code, it will just copy it into its build directory and build it. You can write a trivial script to update and then rebuild or reconfigure your packages. E.g.:

for D in $(ls my-repos/); do
    pushd $D
    svn update
    popd
done
make mypkg1-rebuild mypkg2-reconfigure all

Each developer can use this method with a different set of packages, e.g. only those they are developing.

Solution 2: Put the Buildroot code and all of your package source code in a unique Subversion repo and use <PKG>_SITE_METHOD=local for your packages. When you svn update this big repo, everything will be updated. Then rebuild with make mypkg1-rebuild mypkg2-reconfigure all as above.

A drawback with this solution is that the unique repo might grow very large if you have many packages. It also forces you to use Subversion for everything, and you cannot choose the set of "local" packages as with the first solution.

custom libdrm for buildroot

There are three ways to customize a package:

1. Use the _OVERRIDE_SRCDIR feature. This allows you to modify the source of a package as you like.
2. Edit the package .mk file directly, i.e. package/libdrm/libdrm.mk, and change LIBDRM_VERSION into the version you need. You will also have to update package/libdrm/libdrm.hash with the correct hash, and most likely you also have to update the patches. One way of achieving this is to revert buildroot to 36e69dc2415f4bd2759c29bdd39a289b0a3776f1.
3. Create a new package with a different name, e.g. libdrm2460. The disadvantage of this approach is that if you select other packages that depend on libdrm, they will still force the build of libdrm-2.4.66.

Remember, though, that using a custom version of a package means that you will have to take care of any cross-compilation issues yourself.

How to add my own software to a Buildroot Linux package?

Minimal tested example on top of 2016.05

GitHub upstream:
https://github.com/cirosantilli/buildroot/tree/in-tree-package-2016.05

This example adds the package source in-tree, which is simple for educational purposes and the way to go if you want to merge back (kudos!),

If you do not intend on merging back (booooh!), it is more likely that you will want to use Buildroot as a git submodule and either:

• an out of tree package with BR2_EXTERNAL as shown at: https://github.com/cirosantilli/buildroot/tree/out-of-tree-2016.05
• *_OVERRIDE_SRCDIR + other git submodules as explained at: How to modify the source of Buildroot packages for package development?

Files modified:

package/Config.in

menu "Misc"
    source "package/hello/Config.in"
endmenu

package/hello/Config.in

config BR2_PACKAGE_HELLO
    bool "hello"
    help
        Hello world package.

        http://example.com

package/hello/hello.mk

################################################################################
#
# hello
#
################################################################################

HELLO_VERSION = 1.0
HELLO_SITE = ./package/hello/src
HELLO_SITE_METHOD = local

define HELLO_BUILD_CMDS
    $(MAKE) CC="$(TARGET_CC)" LD="$(TARGET_LD)" -C $(@D)
endef

define HELLO_INSTALL_TARGET_CMDS
    $(INSTALL) -D -m 0755 $(@D)/hello $(TARGET_DIR)/usr/bin
endef

$(eval $(generic-package))

package/hello/src/.gitignore

hello

package/hello/src/Makefile

CC = gcc

.PHONY: clean

hello: hello.c
    $(CC) -o '$@' '$<'

clean:
    rm hello

package/hello/src/hello.c

#include <stdio.h>

int main(void) {
    puts("hello");
}

Usage:

make qemu_x86_64_defconfig
echo 'BR2_PACKAGE_HELLO=y' >> .config
make BR2_JLEVEL=2
qemu-system-x86_64 -M pc -kernel output/images/bzImage -drive file=output/images/rootfs.ext2,if=virtio,format=raw -append root=/dev/vda -net nic,model=virtio -net user

From inside qemu:

hello

Expected output:

hello

Tested in Ubuntu 16.04.

How to apply patches to a package in Buildroot?

After studying the buildroot architecture, I came to know that buildroot uses quilt tool for applying the patches. quilt keeps track of all the patches in the a file named "series" which is present in the "patches" directory. You have to keep your patches in this directory. And add your entry of patches in the series file in the order in which you want the patches to be applied keeping the patch to be applied first at the top.

This way when you will run the buildroot makefile, it will automatically apply the patches listed in the series file.

Buildroot 'make pkg -rebuild' same as 'make pkg '?

make <pkg> builds:

• all the dependencies of <pkg> that have not been built yet
• <pkg> if it has not been built yet

So, if make <pkg> is executed twice in a row, the second call will do nothing.

make <pkg>-rebuild builds:

• all the dependencies of <pkg> that have not been built yet
  (same as above)
• The build and the following steps for <pkg>,
  no matter if they have already been done

So, if make <pkg>-rebuild is executed twice in a row, the second call will not run the extract, patch and configure steps, but it will execute the build and install steps.

make <pkg>-rebuild is used for example when you edit the package build recipe in <pkg>/<pkg>.mk and you want to build it again with the new rules.

Buildroot custom package not built automatically

Enter make menuconfig, enable your package, exit saving changes.
Now make will build your package too.

This is because by default nearly all packages are disabled since Buildroot cannot know what you need on your target root filesystem.

---

Related Topics