Re: RFC: Secondary Toolchain

[Mark Hatle <mark.hatle@windriver.com>]

On 10/4/12 2:03 PM, McClintock Matthew-B29882 wrote:
> On Thu, Oct 4, 2012 at 1:02 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>> We have an issue where we'd like to have an alternative toolchain
>> (assembler, linker, compiler) available for our customers to selectively
>> use.  However, before we just go off and implement something, I'd like at
>> least some basic consensus on what the best practice is for doing this work.
>> Below is my attempt at an early proposal.
>>
>> Background
>> ----------------
>>
>> Many companies have commercial / highly optimized toolchains for specific
>> purpose, such as ICC from Intel, LLVM, ARM specific toolchain, etc..  For
>> (potentially) better performance with some applications a mechanism to both
>> provide the hooks for the alternative toolchain as well as a way to active
>> it per-package is desired.
>>
>> This work assumes that the third party toolchain is generally compatible
>> with the idea of sysroots, linking to the libc provided by OE, and generally
>> compatible with GNU conventions.
>>
>> However, as part of the third party toolchain, it may not be GNU compatible.
>> This means many Open Source applications simply may not work with this
>> toolchain.  That means that we need to have a way for a toolchain to
>> blacklist (or whitelist) specific recipes.  This way only supported
>> components can be built by the user, avoiding numerous complaints.
>>
>> Currently OE has a method to generate an SDK based on the GNU toolchain.  We
>> would like to be able to also export the external toolchain along with the
>> SDK, effectively providing both the GNU toolchain and the third party
>> toolchain using the common sysroot.
>>
>> We need a way to active the third party toolchain on a per-package basis.
>> This activation will need to use the existing sysroot, but be able to pass
>> different C, C++, LD, AS and other flags as specified by the third party
>> toolchain.
>>
>> Finally third party toolchains should be implemented as layers that can
>> easily plug into OE.
>>
>> Implementation
>> ---------------------
>>
>> Add an OVERRIDE to specify the alternative toolchain.  Can this be done
>> within the layer by doing something like:
>>
>> OVERRIDE_append = ":toolchain-${TOOLCHAIN}"
>>
>> TOOLCHAIN = "gnu" (or "icc")
>>
>> To activate the toolchain you would use things like:
>>
>> TOOLCHAIN_pn-bash = 'icc'
>>
>> To define the correct behavior for the toolchain, the following would need
>> to be defined (with _toolchain-<toolchain>):
>>
>> TARGET_CPPFLAGS
>> TARGET_CFLAGS
>> TARGET_CXXFLAGS
>> TARGET_LDFLAGS
>> CC
>> CXX
>> F77
>> CPP
>> LD
>> CCLD
>> AR
>> AS
>> RANLIB
>> STRIP
>> OBJCOPY
>> OBJDUMP
>> NM
>> FULL_OPTIMIZATIONS
>> DEBUG_OPTIMIZATION
>>
>> Is anyone aware of any other items that may require additional items?  Will
>> the above actually work?  Using the override of the TOOLCHAIN_… will that
>> actually change the override values or do we get stuck?
>
> This seems orthogonal to actually implementing the recipe which would
> procide 'icc'?

That is correct.  I'm trying to establish a best practice for the layer 
configuration, as well as general distribution/recipe configuration.

What I really don't want to see is 5 companies implementing similar 
functionality and doing it in a completely incompatible way.  If the variables 
and override mechanism above is reasonable, then it gives people a roadmap to 
get started.

--Mark

> -M
>
>>
>> Comments/suggestions appreciated!
>> --Mark
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core