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] |
On Tue, May 31, 2011 at 5:04 PM, Yann E. MORIN <yann.morin.1998@anciens.enib.fr> wrote: > Bryan, All, > > On Tuesday 31 May 2011 16:36:32 Bryan Hundven wrote: >> On Tue, May 31, 2011 at 5:13 AM, Yann E. MORIN >> <yann.morin.1998@anciens.enib.fr> wrote: > [--SNIP--] >> > +# In case we need to add more conditions to enable static >> > +# toolchain, we'll be adding them here >> > +config STATIC_TOOLCHAIN_POSSIBLE >> > +  Âbool >> > +  Âdefault y >> > +  Âdepends on CONFIGURE_has_static_libstdcxx >> > +  Â# Add new deps here! :-) >> > + >> >> Why? I don't understand why you want a config option with its own set >> of dependencies... this will cause more problems in the future then >> will solve. Another patch I don't get. >> >> Why not just put the dependency in STATIC_TOOLCHAIN where it belongs? > > For this particular case, I agree with you: adding the dependency directly > to the affected symbol would be more appropriate. > > On the other hand, this is begining to be quite complex, and I envision a > situation where the list of dependencies could grow very, very quickly. To > keep that kconfig part readable, it seems more fit to move the CONFIGURE_* > dependencies to an intermediate symbol. > > Apart from the required static libstdc++, we also need to check for other > libs static format being available. At least we need libc.a, probably libm.a > and a few others. > > Another reason is that we may have to disable shared building, and be able > to force static build. Having separate intermediate symbols for the deps > will highly simplify that kconfig part. When you start adding more languages (gnat, objc(++), java... go(?)), each has a set of dependencies. A majority of the problems we see on this mailing list are because the user (person running ct-ng, developer or not...) doesn't have the correct dependencies installed on the build host. And if you want to spend most of your time tracking down a missing dependencies, be my guest. I think that we should stop and re-factor things so that we _can_ check for build host dependencies in a way that doesn't make ct-ng complex. It might squeeze out some other issues indirectly, which would be nice. It also might provide a good dependency framework that llvm/clang or whatever else you want to shoe horn into ct-ng. Just my 2cents. But as I said in irc, this is your project and you do what you see fit. I am merely providing advise via patch (or mq in this case). >> > Âconfig STATIC_TOOLCHAIN >> >   bool >> >   prompt "Build Static Toolchain (EXPERIMENTAL)" >> >   depends on EXPERIMENTAL >> > +  Âdepends on STATIC_TOOLCHAIN_POSSIBLE >> >   default n >> >   help >> >    Build static host binaries. > > 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. Â| > '------------------------------^-------^------------------^--------------------' > -Bryan -- 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] |