Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: RFC: Secondary Toolchain
Date: Thu, 4 Oct 2012 13:02:50 -0500	[thread overview]
Message-ID: <506DCF4A.5020101@windriver.com> (raw)

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



             reply	other threads:[~2012-10-04 18:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-04 18:02 Mark Hatle [this message]
2012-10-04 18:15 ` RFC: Secondary Toolchain Trevor Woerner
2012-10-04 18:38   ` Mark Hatle
2012-10-04 19:03 ` McClintock Matthew-B29882
2012-10-04 20:27   ` Mark Hatle
2012-10-04 20:36 ` Khem Raj
2012-10-04 21:00   ` Mark Hatle
2012-10-04 21:02     ` Khem Raj
2012-10-04 21:16     ` Phil Blundell
2012-10-04 21:31       ` Mark Hatle
2012-11-13 23:37 ` RFC: Secondary Toolchain -- Followup Mark Hatle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=506DCF4A.5020101@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox