On Tue, Mar 30, 2010 at 3:29 AM, Richard Purdie <[email protected]> wrote: > On Tue, 2010-03-30 at 12:14 +0200, Koen Kooi wrote: >> On 30-03-10 11:42, Richard Purdie wrote: >> > On Tue, 2010-03-30 at 11:33 +0200, Koen Kooi wrote: >> >> Can't we have seperate recipes for ssp, stdc++, fortran, java, etc? I >> >> don't think we need USEFLAGs for this when we build them seperately >> >> anyway. >> > >> > We'd not be using USEFLAGS, we'd just be looking at the line which tells >> > gcc itself which bits to build. Having separate recipes doesn't solve >> > the problem since we'd still have to work out whether the compiler for a >> > given lib was built and then we enter a dependency nightmare working out >> > which packages need which combinations of compilers and compiler libs. >> > >> > So we can have separate recipes but think through the issues and see >> > whether you still like the idea... >> >> Let's put it in a different way: >> >> Can we stop artificially limiting the toolchain options and have people >> opt-out instead of opt-in for stuff? I really need a full featured >> toolchain :) > > I see no reason why the default compiler shouldn't be the fully featured > one and then distros and users can turn off the bits they don't want if > they choose to. > > Is that the issue you mean or is there a concern I'm missing? > > I can see the other side though, its a pain having to fight fortran > build failures when upgrading the compiler if you never use fortran. Its > this point where it becomes a pain to have so many old versions of > things as this would be much simpler to arrange and maintain if we had > less gcc versions. I worry about trying to add gcc-runtime to OE for > this reason.
I think we should default to C,C++ which is most commonly used combination but at the same time it would be nice if developer could disable C++ or enable fortran or java or objc, ada, go language or whatever > > [remark about Poky removed] > > Cheers, > > Richard > > > > _______________________________________________ > Openembedded-devel mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
