This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cd crosstool-ng ; make menuconfig


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]