OpenWrt: Split Toolchain for faster Firmware Build Times

At work we’re using Hudson to automatically build projects whenever something is changed in a SCM. For most projects you’ll get fast results if your checkin breaks something which you don’t mind because you not always rebuild the complete project. Now, OpenWrt brings its own toolchain, which compiles the complete local and cross-compiling stuff because the compiler on the host is normally a bit behind and does not contain latest fixes for ARM and other architectures. So how to save some time with not compiling the toolchain everytime a project is build?

For this purpose OpenWrt has a feature called „Use External Toolchain“. This makes it possible to also use vendor-specific toolchains to build OpenWrt. What currently not worked was using OpenWrt itself as its external toolchain. To make this possible, I’ve created some patches (send already to the mailing list/bugzilla) and written some short How-To in the OpenWrt Wiki.

So now the Toolchain is rebuild once a week (but can also be triggered by hand) and the normal firmware is build as usual with a git clean -f -d -x at the beginning.

4 Kommentare

  1. Hi,

    I’m also looking to reduce the build time, but started the investigations using the „Build Toolchain“ option. The build produce an independent toolchain, available in …/bin. Have you examined this option ?

    Actually a have some compilation trouble with the e2fsprogs package, but seems to be an alternative.

  2. Hi David,

    this only would make sense for me if this option would skip the part of compiling device specific stuff like the kernel and userland. But without finding documentation to this feature, its hard for me to tell what it actually does.

    For my development it makes no difference where the toolchain is located, because I need two OpenWrt directories to stay up-to-date with the toolchain and on the other side with the device devel stuff.

    So if the toolchain is updated in trunk, I want to have this changes in time, so I always have the toolchain lying around – and so, why not using it in a standard way?

  3. Hi,

    Why a separated toolchain ? Because there are many developers in the team. So the idea is to compile the toolchain at the project start and to distribute it.

    If only some user package must be compiled, then the SDK make sense for me.

    So seems that we don’t have the same use case

  4. Hi David,

    you are right. For many developers this seems to be a good idea but would need some packaging and distribution mechanism included.

    For our project, which is under heavy development, it’s better when everybody (including the automated build box) can build an up-to-date toolchain without having root permissions (until we consider a Linearo GCC release as final for project release).

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.