Linaro Android Build Tools

Merge lp://qastaging/~berolinux/linaro-android-build-tools/support-dual-toolchain-tarballs into lp://qastaging/linaro-android-build-tools

support-dual-toolchain-tarballs
Merge into trunk

Proposed by Bernhard Rosenkraenzer on 2011-11-03

Status:	Merged
Approved by:	Paul Sokolovsky on 2011-11-12
Approved revision:	360
Merged at revision:	361
Proposed branch:	lp://qastaging/~berolinux/linaro-android-build-tools/support-dual-toolchain-tarballs
Merge into:	lp://qastaging/linaro-android-build-tools
Diff against target:	15 lines (+5/-1) 1 file modified build-scripts/build-android (+5/-1)
To merge this branch:	bzr merge lp://qastaging/~berolinux/linaro-android-build-tools/support-dual-toolchain-tarballs
Related bugs:	Link a bug report

Reviewer	Date Requested	Status
Bernhard Rosenkraenzer (community)		Approve on 2011-11-11
Paul Sokolovsky	2011-11-03	Pending
Review via email: mp+81199@code.qastaging.launchpad.net

Description of the change

Handle toolchain tarballs that contain both a generic arm-eabi- and
an arm-linux-androideabi- toolchain.

Introduce a new TOOLCHAIN_TYPE variable that can be used to select
which of those compilers is used for TARGET_TOOLS_PREFIX (if none
is set, use the first compiler we can find)

At this time, this is necessary so we can start using the arm-linux-androideabi- compiler in some subdirectories while sticking with the arm-eabi- compiler in others. In the long run, it will still be necessary because most of the system will be built with arm-linux-androideabi- while u-boot will always need to be built with arm-eabi-

Revision history for this message

Paul Sokolovsky (pfalcon) wrote on 2011-11-03:

Do you expect for toolchain TOOLCHAIN_TYPE to ever contain wildcards? If no, then whole find/head is apparently superfluous, and there would be direct assignment.

Also, is TOOLCHAIN_TYPE really good name for it? Not TOOLCHAIN_ARCH, TOOLCHAIN_TARGET, TOOLCHAIN_TRIPLET (not suggesting any of them, just asking for consideration). And actually, this falls into what was suggested by Michael Hope at that Parametrization session - to use consistent naming across Linaro teams, so maybe worth checking with him right away?

Revision history for this message

Bernhard Rosenkraenzer (berolinux) wrote on 2011-11-03:

find/head is copied from the old-style build and can probably be simplified a bit - but I'd prefer to leave it in:
find also has the advantage of making sure we get an absolute path there.

I don't expect to use wildcards right now, but I think at some point they may make sense, so there's no point in disallowing them by not using head -- I can for example picture having

TOOLCHAIN_TYPE="*-androideabi"

in a build that can - depending on the toolchain tarball - end up using arm-linux-androideabi (over arm-eabi) or armv8-linux-androideabi (over armv8-eabi) or the exact opposite.

As for the naming, the other names may be better, let's talk to Michael.

Revision history for this message

Michael Hope (michaelh1) wrote on 2011-11-09:

The naming is fine. This prefix is the triplet so 'TOOLCHAIN_TRIPLET' might be better. Many tools like the kernel use CROSS_COMPILE instead.

See:
http://www.gnu.org/s/hello/manual/autoconf/Specifying-Target-Triplets.html#Specifying%20Names

We omit the vendor if it is 'none' so instead of the more common/canonical arm-none-linux-gnueabi we use arm-linux-gnueabi. Same for arm-none-eabi where 'none' means no OS.

lp://qastaging/~berolinux/linaro-android-build-tools/support-dual-toolchain-tarballs updated on 2011-11-11