On 10/4/12 2:03 PM, McClintock Matthew-B29882 wrote:
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'?
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
[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
