[Buildroot] barking up a different tree

[Buildroot] barking up a different tree

[Charles Krinke]

Maybe I am barking up the wrong tree.

Being able to do "make clean" and *not* have to re-compile the uclibc
toolchain would get buildroot to an acceptable point for the uclibc part of
my project.

Would I be correct in assuming that removing "$(TOOLCHAIN_DIR) from the
Makefile clean target would get to a place where I can do "make clean &&
make" and still have the previously compiled uclibc toolchain?

-- 
Charles Krinke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110423/84526b7d/attachment.html>

[Buildroot] barking up a different tree

[Peter Korsgaard]

>>>>> "Charles" == Charles Krinke <charles.krinke@gmail.com> writes:

 Charles> Maybe I am barking up the wrong tree.

 Charles> Being able to do "make clean" and *not* have to re-compile the
 Charles> uclibc toolchain would get buildroot to an acceptable point
 Charles> for the uclibc part of my project.

Just build it once somewhere (E.G. set BR2_HOST_DIR to /opt/toolchain or
whatever), and then just configure BR to use it as an external
toolchain.

-- 
Bye, Peter Korsgaard

[Buildroot] barking up a different tree

[William Wagner]

On 23/04/2011 21:38, Peter Korsgaard wrote:
>>>>>> "Charles" == Charles Krinke<charles.krinke@gmail.com>  writes:
>   Charles>  Maybe I am barking up the wrong tree.
>
>   Charles>  Being able to do "make clean" and *not* have to re-compile the
>   Charles>  uclibc toolchain would get buildroot to an acceptable point
>   Charles>  for the uclibc part of my project.
>
> Just build it once somewhere (E.G. set BR2_HOST_DIR to /opt/toolchain or
> whatever), and then just configure BR to use it as an external
> toolchain.

Peter,

I know that your solution works and it's what you say to everybody who 
asks that question. However I feel it is the worst feature of buildroot 
and the things that most often puts people off when I explain it. Why 
not change it so that buildroot normally does a build as if to a 
different location and then automatically uses that for the actual build 
as we clearly have support for copying the correct bits. I can't really 
see any disadvantage of this over the current system and it would 
finally allow users to get back to a clean target build but still with 
the toolchain built. I would attempt this myself to submit as a patch 
but I've not had to hack around with the toolchain much, however if 
others can give me some pointers I'd happily look at it, otherwise if 
someone else tried it I'd certainly test it.

Will

-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner at carallon.com
Development Manager                      Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

[Buildroot] barking up a different tree

[Charles Krinke]

I understand that one can build it once and move it.

The issue I have is supporting half a dozen engineers.

Every time I suggest something not quite logical, I get hours (or days) of
discussions up to and including "let use OpenEmbedded", which I am really
tired of hearing.

So, .... I am trying to get a better way  then the /opt/other.



On Sat, Apr 23, 2011 at 1:46 PM, William Wagner <will_wagner@carallon.com>wrote:

> On 23/04/2011 21:38, Peter Korsgaard wrote:
>
>> "Charles" == Charles Krinke<charles.krinke@gmail.com>  writes:
>>>>>>>
>>>>>>  Charles>  Maybe I am barking up the wrong tree.
>>
>>  Charles>  Being able to do "make clean" and *not* have to re-compile the
>>  Charles>  uclibc toolchain would get buildroot to an acceptable point
>>  Charles>  for the uclibc part of my project.
>>
>> Just build it once somewhere (E.G. set BR2_HOST_DIR to /opt/toolchain or
>> whatever), and then just configure BR to use it as an external
>> toolchain.
>>
>
> Peter,
>
> I know that your solution works and it's what you say to everybody who asks
> that question. However I feel it is the worst feature of buildroot and the
> things that most often puts people off when I explain it. Why not change it
> so that buildroot normally does a build as if to a different location and
> then automatically uses that for the actual build as we clearly have support
> for copying the correct bits. I can't really see any disadvantage of this
> over the current system and it would finally allow users to get back to a
> clean target build but still with the toolchain built. I would attempt this
> myself to submit as a patch but I've not had to hack around with the
> toolchain much, however if others can give me some pointers I'd happily look
> at it, otherwise if someone else tried it I'd certainly test it.
>
> Will
>
> --
> ------------------------------------------------------------------------
> Will Wagner                                     will_wagner at carallon.com
> Development Manager                      Office Tel: +44 (0)20 7371 2032
> Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
> ------------------------------------------------------------------------
>
>
>


-- 
Charles Krinke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110423/e0dd841e/attachment-0001.html>

[Buildroot] barking up a different tree

[ANDY KENNEDY]

> -----Original Message-----
> From: buildroot-bounces at busybox.net [mailto:buildroot-
> bounces at busybox.net] On Behalf Of Charles Krinke
> Sent: Saturday, April 23, 2011 4:02 PM
> To: William Wagner
> Cc: buildroot
> Subject: Re: [Buildroot] barking up a different tree
> 
> I understand that one can build it once and move it.
> 
> The issue I have is supporting half a dozen engineers.
> 
> Every time I suggest something not quite logical, I get hours (or
> days) of discussions up to and including "let use OpenEmbedded",
> which I am really tired of hearing.
> 
> So, .... I am trying to get a better way  then the /opt/other.
> 
> 

If you are attempting to build a uClibC toolchain for your engineers, why not just build the toolchain (under /opt/toolchains -- like Peter said), then make a tar ball of that dir and have your eng's unzip it.  Viola!  You have it.   Then, they can build buildroot to their hearts content and all will be great.

Now, to build the external toolchain, you can either use Yann's crosstool-NG, OR, you can have a prelim build of buildroot dropping a toolchain into that dir.  IF your eng's need to build it themselves (I know that feeling, I have a couple that don?t want binaries, they want source) fix that package up and wrap the whole process in a make file.  Keep control over what they do by having them run a build (so that they don?t screw it up).  Save off all your config files to a common dir, then have the make file unpack, update, configure and build the toolchain and the file system.  This isn?t "easy" but it is probably the best thing to do.

Andy