From: Ulf Samuelsson <ulf@atmel.com>
To: buildroot@busybox.net
Subject: [Buildroot] per-project uclibc configuration does notreally w ork
Date: Fri, 2 Nov 2007 07:23:03 +0100 [thread overview]
Message-ID: <004101c81d19$0de49050$01c4af0a@Glamdring> (raw)
In-Reply-To: 20071102001137.GB18120@cloud.net.au
> 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
prev parent reply other threads:[~2007-11-02 6:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-01 17:16 [Buildroot] per-project uclibc configuration does not really w ork Ulf Samuelsson
2007-11-02 0:11 ` Hamish Moffatt
2007-11-02 6:23 ` Ulf Samuelsson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='004101c81d19$0de49050$01c4af0a@Glamdring' \
--to=ulf@atmel.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox