[OE-core] RFC: Secondary Toolchain -- Followup

[Mark Hatle]

I have taken the RFC added it to the OE Wiki -- as well as added example 
details.  I've got most of the information implemented now, only the SDK 
specific items are remaining.

I'm looking for people to review this and let me know if the contents are 
reasonable or not -- and if you have any suggestions or comments.

http://www.openembedded.org/wiki/Adding_a_secondary_toolchain

Once the document is complete, and all of the comments are addressed, I expect 
this will become the 'standard' way to implement and control a secondary toolchain.

On 10/4/12 1:02 PM, Mark Hatle 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?
>
> Comments/suggestions appreciated!
> --Mark
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>