Please note that User Registration has been temporarily disabled due to a recent increase in automated registrations. If anyone needs an account, please request one here: RequestAccount. Thanks for your patience!

Difference between revisions of "Adding a secondary toolchain"

From Openembedded.org
Jump to: navigation, search
(How to add an alternative/secondary toolchain to or-core)
 
Line 1: Line 1:
Test
+
== Background ==
 +
 
 +
In OpenEmbedded-Core there in an included toolchain that is built up of GNU binutils, gcc, and eglibc.  In addition related components such as gdb, cross-prelink, mklibs and others provider additional toolchain functionality.  In this document we focus on explaining best practices for including an additional toolchain that is capable of assembling, compiling and linking code.  This document does not cover replacing the existing toolchain or toolchain components with external elements.
 +
 
 +
Many companies have commercial / highly optimized toolchains for specific purposes, such as ICC from Intel, LLVM, ARM Ltd toolchains, etc..  In some cases, these highly optimized toolchains may result in better performance for some applications, however they are often not generally applicable as they can not compile all of the system software.  So instead of replacing the included GNU toolchain, a mechanism for providing an alternative/secondary toolchain is desired.
 +
 
 +
== Requirements ==
 +
 
 +
'''Secondary Toolchains should be implemented in a layer'''
 +
 
 +
In order to facilitate re-use and make it easier to completely disable the secondary toolchain, a layer must be used to implement the secondary toolchain.
 +
 
 +
'''Secondary Toolchain must be generally compatible with GNU toolchain'''
 +
 
 +
The secondary toolchain must be generally compatible with the idea of sysroots, linking to the defined libc, and various GNU conventions.  This compatibility may be implemented directly by the secondary toolchain or via a wrapper of some type.
 +
 
 +
'''Per recipe selection of toolchain usage'''
 +
 
 +
A mechanism is needed to activate this alternative toolchain on a per-recipe basis.  Using variables it should be possible to specify on a per-recipe basis which toolchain should be used, leaving the default up to the user.  (It's assumed if the user does not select a default, the system GNU toolchain will be defaulted.)
 +
 
 +
'''Blacklist/Whitelist'''
 +
 
 +
Even with the requirement to be generally compatible, we can not expect all of the possible recipes to build properly with the secondary toolchain.  As a consequence of this, it will be necessary to implement a blacklist (or whitelist) of specific recipes that are known to work.  This way only supported components can be build by the user, avoid numerous complaints and unresolvable defects.
 +
 
 +
'''SDK'''
 +
 
 +
The SDK generated by OpenEmbedded-Core also includes the included toolchain components.  It would be useful to also provide support for the secondary toolchain within the SDK environment.
 +
 
 +
== Implementation ==
 +
 
 +
== Further comments and information ==
 +
 
 +
[[Category:Dev]]
 +
[[Category:Layers]]

Revision as of 18:31, 13 November 2012

Contents

Background

In OpenEmbedded-Core there in an included toolchain that is built up of GNU binutils, gcc, and eglibc. In addition related components such as gdb, cross-prelink, mklibs and others provider additional toolchain functionality. In this document we focus on explaining best practices for including an additional toolchain that is capable of assembling, compiling and linking code. This document does not cover replacing the existing toolchain or toolchain components with external elements.

Many companies have commercial / highly optimized toolchains for specific purposes, such as ICC from Intel, LLVM, ARM Ltd toolchains, etc.. In some cases, these highly optimized toolchains may result in better performance for some applications, however they are often not generally applicable as they can not compile all of the system software. So instead of replacing the included GNU toolchain, a mechanism for providing an alternative/secondary toolchain is desired.

Requirements

Secondary Toolchains should be implemented in a layer

In order to facilitate re-use and make it easier to completely disable the secondary toolchain, a layer must be used to implement the secondary toolchain.

Secondary Toolchain must be generally compatible with GNU toolchain

The secondary toolchain must be generally compatible with the idea of sysroots, linking to the defined libc, and various GNU conventions. This compatibility may be implemented directly by the secondary toolchain or via a wrapper of some type.

Per recipe selection of toolchain usage

A mechanism is needed to activate this alternative toolchain on a per-recipe basis. Using variables it should be possible to specify on a per-recipe basis which toolchain should be used, leaving the default up to the user. (It's assumed if the user does not select a default, the system GNU toolchain will be defaulted.)

Blacklist/Whitelist

Even with the requirement to be generally compatible, we can not expect all of the possible recipes to build properly with the secondary toolchain. As a consequence of this, it will be necessary to implement a blacklist (or whitelist) of specific recipes that are known to work. This way only supported components can be build by the user, avoid numerous complaints and unresolvable defects.

SDK

The SDK generated by OpenEmbedded-Core also includes the included toolchain components. It would be useful to also provide support for the secondary toolchain within the SDK environment.

Implementation

Further comments and information

Personal tools
Namespaces

Variants
Actions
Navigation
Categories
OE services
Toolbox