[Buildroot] per-project uclibc configuration does not really w ork

[Buildroot] per-project uclibc configuration does not really w ork

[Ulf Samuelsson]

buildroot's project support (eg saveconfig target) appears to offer
per-project uClibc .config support and per-project uClibc version selection.

=> Once you have built 
  the toolchain for one
  project the rest of
  the projects should
  use that as an external
  toolchain and none of the
  gcc,binutils,uClibc 
  configuration items in
  Toolchain should be
  changed.



However, uclibc is built into the per-arch toolchain_build_$(ARCH) 
directory and installed into build_$(ARCH), rather than the per-project
build directory project_build_$(ARCH)/$(PROJECT). And so is the gcc
cross-compiler built against that uclibc.

Only a few packages build into the per-project build directly, name
busybox and uclibc. The problem is that if you change your uclibc
configuration you may well need to rebuild all your programs too,
because autoconf tests might return different results etc.

=> AII configurable packages
  should be built ln 
  project-build-arch if
  the reconfiguration results
  in the package binaries
  changing shape.
  If the package builds
  several binaries and
  the configuration only
  changes which binaries
  are copied to the 
  target dir, then the
  package can be built in
  build-dir.

Effectively you have to build everything per-project (including the
whole toolchain).

=> Dont change the toolchain
   and you get the benefit.

Is there much benefit in trying to share package builds between
projects, as buildroot does right now?

=> Yes, if you build several
   boards with a common
   toolchain you reduce
   the build time for each
   package to a fraction
   of a second.


Best Regards
Ulf Samuelsson

[Buildroot] per-project uclibc configuration does not really w ork

[Hamish Moffatt]

On Thu, Nov 01, 2007 at 06:16:00PM +0100, Ulf Samuelsson wrote:
> buildroot's project support (eg saveconfig target) appears to offer
> per-project uClibc .config support and per-project uClibc version selection.
> 
> => Once you have built 
>   the toolchain for one
>   project the rest of
>   the projects should
>   use that as an external
>   toolchain and none of the
>   gcc,binutils,uClibc 
>   configuration items in
>   Toolchain should be
>   changed.

OK. So if I have 2+ projects I wish to build using a common toolchain,
would you suggest making an additional project just to build the
toolchain (no packages, no target filesystems) then setting the other
projects to all use an external toolchain?

> Is there much benefit in trying to share package builds between
> projects, as buildroot does right now?
> 
> => Yes, if you build several
>    boards with a common
>    toolchain you reduce
>    the build time for each
>    package to a fraction
>    of a second.

Once the toolchain is common, you could achieve most of the same
speedup using ccache, but guarantee the correct results. The current
scheme can't guarantee that; you don't know what autoconf might pick up
which is target specific (other installed packages etc).

Admittedly if you build a toolchain for each project then you can't 
effectively use ccache (the compiler will appear to be different, even
if it is actually the same).


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] per-project uclibc configuration does notreally w ork

[Ulf Samuelsson]

> On Thu, Nov 01, 2007 at 06:16:00PM +0100, Ulf Samuelsson wrote:
>> buildroot's project support (eg saveconfig target) appears to offer
>> per-project uClibc .config support and per-project uClibc version 
>> selection.
>>
>> => Once you have built
>>   the toolchain for one
>>   project the rest of
>>   the projects should
>>   use that as an external
>>   toolchain and none of the
>>   gcc,binutils,uClibc
>>   configuration items in
>>   Toolchain should be
>>   changed.
>
> OK. So if I have 2+ projects I wish to build using a common toolchain,
> would you suggest making an additional project just to build the
> toolchain (no packages, no target filesystems) then setting the other
> projects to all use an external toolchain?
>

It is a matter of taste. You can do it either way.
I ususally just build to toolchain with one project
and set the toolchain parameters to the same for the other projects.

It is probably better to have one project to build the toolchain.

>> Is there much benefit in trying to share package builds between
>> projects, as buildroot does right now?
>>
>> => Yes, if you build several
>>    boards with a common
>>    toolchain you reduce
>>    the build time for each
>>    package to a fraction
>>    of a second.
>
> Once the toolchain is common, you could achieve most of the same
> speedup using ccache, but guarantee the correct results. The current
> scheme can't guarantee that; you don't know what autoconf might pick up
> which is target specific (other installed packages etc).
>

I dont see how ccache can help you to speed up building one source
tree just because you have built another source tree containing the
iden tical code and a different ccache directory.


> Admittedly if you build a toolchain for each project then you can't
> effectively use ccache (the compiler will appear to be different, even
> if it is actually the same).
>
>
> Hamish
> -- 
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
>


Best Regards
Ulf Samuelsson