How to get a buildroot project under source control

Question

The company I work for develops a product that requires embedded Linux for which we use, as many other, Buildroot.

In any case, I would like to get the project under source control using Git, as it is our tool for source control for all the other projects the company has. The problem is that I don't know which files should I keep in source control (as keeping the whole buildroot directory seems overkilling).

Wilbertwilborn

How to track package modifications: #40334195 – Reinareinald

Answer 1

I've tackling this same issue by working with git submodules and buildroot br-external feature.

In this sense, you only need to start an empty repository and import a buildroot release as a submodule of it.

mkdir myrepo; cd myrepo
git init
touch README; git add README; git commit -m "Initial commit"
git submodule add -b <preferred release/tag/branch> git://git.buildroot.net/buildroot
git submodule update --init

Then you can create a br-external directory and populate it similar as buildroot's own package/configs/board directories as explained in BR2_EXTERNAL documentation1.

mkdir br-external
# below command assumes you have all structures ready somewhere else
cp -fva .../configs .../package .../board br-external
touch br-external/{Config.in,external.mk}
(edit Config.in and external.mk)
git add br-external

After doing so, you only need to run buildroot defconfig step passing the absolute path to your br-external directory, like this.

make BR2_EXTERNAL=$PWD/br-external -C buildroot <boardname>_defconfig

Your BR2_EXTERNAL locations gets cached for further invocations.

The nicest parts of this is that you only need to versionate what's inside br-external and buildroot builds up the configuration menu in a way that all your custom stuff gets properly separated ("User provided options" menu entry).

Also, if you decide to bump-up buildroot release to a newer one, the only trouble is to upgrade the submodule and commit it. Perfect for configuration management.

cd buildroot
git pull origin latest-release
cd ..
git add buildroot
git commit -m 'buildroot latest-release upgrade'

Potherb

Very interesting! But if I run make menuconfig or make linux-menuconfig and do some changes there. Would these changes be also inside the br-external folder? – Alonsoalonzo

@eDeviser, buildroot provides targets for automatically updating those configurations (see BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE, linux-update-defconfig, savedefconfig). But once you figure out the proper configurations it seems better to keep them as fragments into your target overlay directory. – Potherb

Answer 2

I've recently tackled the same problem in our organisation, and I find this an interesting topic. I'll describe our partial solution here:

Manage which buildroot version you use

EDIT: Recent experience has emphasized this point for me.

Buildroot writes a different config files for each version of Buildroot. To be able to share these you need to specify to everyone involved which version of Buildroot your repository uses.

1. You could include Buildroot as a git submodule in your repo. Ok, if your company only has one Buildroot project.
2. Specify in the README file which version to use, or write a custom check for it.

Building out-of-tree

I strongly recommend to build out of tree: http://buildroot.org/downloads/manual/manual.html#_building_out_of_tree

$ cd ~/platform/proj-arm; make O=$PWD -C path/to/buildroot

Add configuration files and target overlay to git

Add the .config file and sub-configuration files to the git repository. My repo contains the following:

.config
README.md
linux.config
build/busybox-1.22.1/.config
libdc1394.patch
opencv_2.3.1a.patch
target-overlay/README~
target-overlay/etc/dropbear/dropbear_ecdsa_host_key
target-overlay/etc/dropbear/dropbear_rsa_host_key
target-overlay/etc/fstab
target-overlay/etc/httpd.conf
target-overlay/etc/init.d/S51mount_html
target-overlay/etc/init.d/S52new_ip_address
target-overlay/etc/init.d/S53httpd
target-overlay/etc/network/interfaces
target-overlay/etc/shadow
target-overlay/etc/sshd_config
target-overlay/lib/firmware/rtl_nic/rtl8168g-2.fw
target-overlay/root/.ssh/authorized_keys

Save your changes to buildroot as patches

Whenever you change stuff in the buildroot repository, branch out for that feature, and create a patch for it. Keep the patch in your repository, and use the README.md file to explain to others how to apply it to the buildroot tree.

Heavierthanair

> Whenever you change stuff in the buildroot repository, branch out for that feature I'd recommend to use the submodule, only use tagged versions of buildroot, and put all your commits on top. Then when you want to upgrade, pick another tagged version, and rebase everything on top of that. And here is a minimal out of tree build example: github.com/cirosantilli/buildroot/tree/out-of-tree-2016.05 – Reinareinald

Great approach. Thank You! How did you figure out which files to put in git repository? Your lists looks good. But I am afraid if Buildroot uses some more files which I am not aware of. – Alonsoalonzo

Answer 3

You have two basic options.

1. The easiest is to clone the buildroot repository (it's not very large) and create your own branch based off a release tag. This makes it easy for you to make modifications to buildroot, but it is difficult to make global tags and branches (i.e. giving the same tag to buildroot and to your own code). However, if you want to combine it with the repository of your own code (so everything can be tagged together), you have to use git submodules or subtree merging (neither of which is very convenient), or you have to keep it as a separate repository and use the second solution for integration.
2. You can base your product on a buildroot tarball and write a build script that downloads the tarball, extracts it, configures it (by calling *make xxx_defconfig*) and builds it. The recently added BR2_EXTERNAL mechanism (to be released in 2014.02) makes it easy to keep your own additions outside of the buildroot tree. However, if you need to change anything in the core infrastructure, you have to apply patches on the downloaded tarball, which is inconvenient.

It certainly is not a good idea to extract a buildroot tarball in your repository and import it like that, because that makes it difficult to update your buildroot tree or even to apply upstream patches. If you do want it in your own repository, use git subtree merge so that at least you keep the upstream history.

A third option is to use Android's repo tool to combine the git repositories of buildroot, linux, your own code and other packages you modify. This combines the best of the two options I gave (easy to modify and supports global tags/branches). But I've never tried that myself so I can't promise that it will work well.

Margarethe