[OE-core] RFC: Secondary Toolchain

[McClintock Matthew-B29882]

On Thu, Oct 4, 2012 at 1:02 PM, Mark Hatle <mark.hatle at 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'?

-M

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