[oe] Standalone gcc library builds

[Khem Raj]

On Tue, Mar 30, 2010 at 3:29 AM, Richard Purdie <rpurdie at rpsys.net> 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
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>