All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan Hoffmann <sho@relinux.de>
To: buildroot@busybox.net
Subject: [Buildroot] Report from the Buildroot Developers Meeting
Date: Tue, 12 Feb 2013 12:49:15 +0100	[thread overview]
Message-ID: <511A2C3B.70604@relinux.de> (raw)
In-Reply-To: <20130212113628.00ce121d@skate>

Am 12.02.2013 11:36, schrieb Thomas Petazzoni:
> Dear Stephan Hoffmann,
>
> On Tue, 12 Feb 2013 11:30:00 +0100, Stephan Hoffmann wrote:
>

>>> Switching to ct-ng as the default toolchain backend has been in the
>>> plans for several years. But since it's not the default backend it
>>> isn't getting a lot of attention (example: for several months it was
>>> broken, libraries were not copied to the target, and it took a lot
>>> of time for somebody to notice). 
>> Regarding the toolchain I want to say that I really like buildroot's
>> ability to build a toolchain.
>>
>> But I hate the fact that after every "make clean" the toolchain has to
>> be rebuilt completely from scratch which takes precious time.
>>
>> Of course there is the possibility to change the output directory,
>> build the toolchain and then use it as an external toolchain, but
>> this breaks the nice integration between buildroot and it's toolchain
>> and is not really comfortable.
>>
>> What about automating this process by splitting it up into building
>> the toolchain and afterwards copying it to output/{host/staging} like
>> it is done with external toolchains? "make clean" or maybe something
>> new like "make almostclean" would not clean the toolchain build
>> directory, so only the copy stage would be repeated. Another make
>> target to clean everything including the toolchain would be needed,
>> of course.
> Why don't you build your external toolchain once, put it in a tarball,
> and then point Buildroot to it?
Because, as I wrote, I like the concept to have it integrated in
buildroot's configuration.
>  You have to do this only once, and you
> can even put your toolchain tarball on a server so that others can use
> it without having to rebuild the toolchain.
>
What's the advantage of your proposal against using ct-ng to build the
toolchain or use a prepared one from somewhere else?

Kind regards

Stephan

>
> Best regards,
>
> Thomas


-- 
reLinux     -    Stephan Hoffmann
Am Schmidtgrund 124    50765 K?ln
Tel. +49.221.95595-19    Fax: -64
www.reLinux.de     sho at reLinux.de

  reply	other threads:[~2013-02-12 11:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-08 23:42 [Buildroot] Report from the Buildroot Developers Meeting Thomas Petazzoni
2013-02-12 10:30 ` Stephan Hoffmann
2013-02-12 10:36   ` Thomas Petazzoni
2013-02-12 11:49     ` Stephan Hoffmann [this message]
2013-02-12 11:53       ` Thomas Petazzoni
2013-02-12 11:55   ` Stefan Fröberg
2013-02-12 14:14 ` Daniel Nyström
2013-02-12 14:18   ` Thomas Petazzoni
2013-02-12 15:57     ` Daniel Nyström
2013-02-13 18:55 ` Yann E. MORIN
2013-02-13 19:54   ` Thomas Petazzoni
2013-02-14 14:25   ` [Buildroot] Google Summer of Code 2013 Thomas Petazzoni
2013-03-03 13:43     ` Thomas Petazzoni
2013-03-03 17:29       ` Thomas De Schampheleire
2013-03-03 17:51       ` Stephan Hoffmann
2013-03-03 18:26         ` Thomas Petazzoni
2013-03-05  6:25           ` Arnout Vandecappelle
2013-03-05 18:32             ` Thomas Petazzoni
2013-03-06  8:57             ` Jérôme Pouiller

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=511A2C3B.70604@relinux.de \
    --to=sho@relinux.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.