Re: cd crosstool-ng ; make menuconfig

[Anthony Foiani <anthony dot foiani at gmail dot com>]

Andy --

On Wed, Jun 1, 2011 at 9:04 AM, ANDY KENNEDY <ANDY.KENNEDY@adtran.com> wrote:
> It is a
> piece of a build system. ÂAnother package that allows me an means
> to my ends. ÂSo, just like with buildroot sources, I extract your
> utility into its on little sandbox, build the toolchain using pre-
> downloaded source tarballs, install into a pre-defined location
> based upon environmental vars that I set in my build system,
> configure for local only, build the toolchain, and abandon the
> utility in place -- to be cleaned up later if the end user so
> chooses. ÂIn fact, I unpack a crosstool-ng dir for EACH project
> so as not to collide with anything else I have going on (I mod
> in place the crosstool-ng dir for each project/build). ÂSo, much
> like I don't ever expect to "install" BuildRoot anywhere, I don't
> allow crosstool-ng to install either.

I found that doing a system-wide install is actually the right thing
for me.  I'm building for three similar (but not identical) targets,
and I'm building the same sources for all three. In this case, I
install ct-ng once per build host, then use the one installed instance
of ct-ng to build three different toolchains (and then apps and then
filesystems) by keeping different .config files for each target.

This actually sounds close to your needs; you might consider this mode
instead of trying to shoehorn ct-ng into each project. One of the few
reasons for keeping different versions of ct-ng around would be to
deal with older code bases, but even that seems like a stretch.

On the other hand, how much harder is it (in your overall build
system) to simply unpack ct-ng, then create a sibling directory (say,
ct-ng-build) and install the ct-ng bits there? Or, if you like, have
ct-ng/{src,build} and then blow away the entire ct-ng directory when
you're done?

Best regards,
Tony

--
For unsubscribe information see http://sourceware.org/lists.html#faq