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] |
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] |