Update project-specific packages in buildroot

Question

I am using buildroot with external tree for my project. Buildroot is using to build project with several custom packages which stored in svn, and developing by our developers. How can i update these packages from repository for each build? Build-in download helper downloads package once and store it into archive, but i am need to update it from source each time then i build it. Do i need write my own download helper for this? The only thing I came up with was storing the entire buildroot configuration in the svn repository (include *.mk files of packages), add svn-extrenal property to them, and use 'local' download rule

Answer 1

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.