[Buildroot] [PATCH 2/2] configs: add autobuild configs

[Thomas Petazzoni <thomas.petazzoni@free-electrons.com>]

Hello,

On Sun, 26 Mar 2017 21:43:15 +0200, Arnout Vandecappelle
(Essensium/Mind) wrote:
> We currently have a list of toolchain configurations that are used by
> the autobuilders at [1]. However, this makes it a little more difficult
> for people to use these configurations, and also to have a different
> list of configurations for different branches. For example if a new
> architecture is introduced, the 2017.02.x branch doesn't have support
> for this architecture yet so it shouldn't try to run those configs.
> 
> Therefore, include the autobuild defconfigs directly in Buildroot, so
> they can be branched together with the rest. To avoid polluting the
> configs/ directory too much, the autobuild defconfigs are kept in an
> "autobuild" subdirectory.
> 
> The toolchain-configs.csv file also contained additional information:
> the hostarch required by the toolchain binary, and the libc used. The
> latter can be found in the defconfig itself,

How is the latter found in the defconfig? For example, with:

+BR2_HOSTARCH="x86"
+BR2_x86_pentium4=y
+BR2_TOOLCHAIN_EXTERNAL=y
+BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_X86=y

How will the autobuilder script know that it is a glibc toolchain?

> but the hostarch isn't in
> there. To avoid still having to maintain a separate file, we just add a
> BR2_HOSTARCH string to the defconfig file. When the defconfig is used
> this string is completely ignored, but it can be used by the
> autobuild-run script.

So this BR2_HOSTARCH option needs to be added manually to the
defconfig: the defconfig are not directly the result of "make
savedefconfig", correct?

> Instead of this approach, I also considered adding the
> buildroot-generated toolchains as external toolchains to the menus.
> However, then there would still be a need for config files that specify
> the subarch used, as well as e.g. STATIC. While with this approach the
> entire toolchains/configs directory can be removed from
> autobuild.buildroot.net.

I also think this approach doesn't make much sense, because several of
the autobuild toolchains really don't make sense to have exposed in
Buildroot external toolchain menu. Some toolchain configurations only
exist just for the sake of testing interesting combinations.

Examples: the ARM no-thread toolchain, the basic PowerPC toolchain with
just C++ support, the ARM/glibc toolchain that intentionally always
uses the latest available version of gcc/binutils/glibc, etc.

Other than the issues raised above, I'm generally fine with the idea, I
think it makes sense. If we are going to change the architecture of the
autobuild-run there are lots of different things that could be done:

 - Testing different branches, like you are suggesting.

 - Change how "exceptions" are handled. Currently, people have to
   update their autobuild-run script to have the updated list of
   exceptions. It would be nice if this was not necessary, either by
   having the configuration generated by the autobuild server, or by
   having this list of exceptions in Buildroot itself so that it gets
   naturally updated when pulling the latest version of the source code.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com