On Thu, Oct 4, 2012 at 1:02 PM, Mark Hatle <[email protected]> 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 > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
