cd crosstool-ng ; make menuconfig
Yann E. MORIN
yann.morin.1998@anciens.enib.fr
Thu Jun 2 10:06:00 GMT 2011
Andy, All,
On Wednesday 01 June 2011 17:04:52 ANDY KENNEDY wrote:
[--SNIP--]
> But you see, I don't see this as a program at all.
[--SNIP--]
> It is a piece of a build system.
Oh! Now, I see and understand what you mean. :-)
> 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.
That's about what is being done with buildroot when using crosstool-NG
as the backend: buildroot extract crosstool-NG, configures with --local,
and call it from there. Then, once the toolchain is built, crosstool-NG
is no longer of any use.
This is a one-time process.
What I don't get is why your upper-layer build system wants to call
'make menuconfig', when the exact same would be achieved by calling
'./ct-ng menuconfig' ?
Or do you expect the user of the build system to be able to call the
crosstool-NG's menuconfig on its own? What we've done in buildroot is
add a new target in the buildroot Makefile that the user can call to
configure the crosstool-NG backend:
make ctng-menuconfig
This way, from the top-level buildroot tree ( or from $(O) ), the user
calls 'make ctng-menuconfig' and buildroot handles all the nity-grity work
of building crosstool-NG's (host-)dependencies, downloading crosstool-NG,
configuring it with --local, and calling './ct-ng menuconfig' from the
proper place.
Maybe you could add such a similar entry to your build system? (Not saying
that your alternative proposal is worse, I am just trying to understand.)
> Bottom line: This is not an application to me, but a fancy
> build environment that builds me a neat, shiny, well-built
> toolchain package that I can use to do my job. Much like with
> all the examples you defined, the "application" for me is gcc,
> gdb, ar, as, ld, {e{,g},uc}libc, etc and crosstool-ng is my
> ./configure && make && make install.
Ack, I see your point. You see crosstool-NG as a kind of wrapper to the
many ./configure for all this components. That's a point of view that is
no less valid than what I exposed.
But I believe the way we handle in it buildroot could also be applied to
your case.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
--
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc
mailing list