lunch can now take combos in the form:
$TARGET_PRODUCT
$TARGET_PRODUCT-$TARGET_BUILD_VARIANT
$TARGET_PRODUCT-$TARGET_BUILD_VARIANT-$TARGET_PLATFORM_VERSION
If all 3 are not specified the unspecified ones will take the
default values provided by the build system (eng, and currently
OPR1).
In addition, error handling for invalid products, variants and
versions is moved to the build system.
Bug: 34972208
Test: build/make/tests/envsetup_tests.sh
Change-Id: Ib0aaa98633448ba9bd8df911704c9cb3a8ebbe85
AUX is a new class, similar to TARGET
While TARGET defines toolchain for Application Processors
AUX is defining toolchains for arbitrary utility cores (DSPs, GPUs,
MCUs, etc). This allows building of non-android sources as part
of Android tree and avoid using prebuilts if source code is avaliable
Bug: 29635686
Change-Id: Ie755ea054b16c3e86369f5fb2ba6eb0b384af77f
Signed-off-by: Alexey Polyudov <apolyudov@google.com>
1. Combined ~10 calls to the make build system to only one.
We added a phony target "dump-many-vars" to the build system to dump
"<var>=<value>" pairs. We then store the pairs as shell variables.
With this cache get_build_var/get_abs_build_var can just return
the shell variables instead of querying the build system.
2. Prune .git when we search for AndroidProduct.mks.
In internal source tree lunch time was reduced from ~15s to ~1.5s.
Bug: 27429759
Change-Id: I24e88598f6fab598ef26518885fd5e86e71a772d
This is mostly the same as the existing 2ND_HOST / HOST_CROSS support.
The interesting thing I did here was make x86 the 'first' architecture,
and x86_64 the second. This way LOCAL_MULTILIB := first defaults to
32-bit windows modules.
windows-x86/bin <- defaults to 32-bit executables
windows-x86/lib <- 32-bit libraries, like before
windows-x86/lib64 <- 64-bit libraries
windows-x86/obj <- 32-bit intermediates
windows-x86/obj64 <- 64-bit intermediates
Then modules are registered with the names:
host_cross_liblog <- 32-bit, like before
host_cross_liblog_64 <- 64-bit
Bug: 26957718
Change-Id: I9f119411acb43e973ec1e6bca3c1dc291c91556c
config.mk needs to know TARGET_BUILD_PDK in order to select prebuilt
tools. Move the selection of TARGET_BUILD_PDK into config.mk.
Change-Id: I1f73c92917887f27259b2db64b3779a2fe0df162
Instead of using recursive make to change the HOST_OS when building the
windows SDK under linux, add the concept of cross-building to another
host os.
Bug: 23566667
Change-Id: I6dc525b601b6251d458d197c30bf4660d7485502
It seems the code was meant to add the toolchain to ANDROID_BUILD_PATHS
and then export to PATH by lunch.
But now we export the toolchain to PATH explicitly in envsetup.sh and
the code is unnecessary.
This reduces the places to change when we upgrade the gcc version.
It also fixed the bug that the mips toolchain was always exported
regardless of the target arch.
Change-Id: Iee3b895b4c4e0df8971c27c01b9ecbd591848b12
Switch from gcc-4.7 32-bit only to gcc-4.7 multilib (32/x32/64) compiler.
Tested x86 image build on Linux and Darwin.
This bionic patch is required:
https://android-review.googlesource.com/#/c/64183
Change-Id: Ifc2c6c5d6a4a1b71a00a87af072bb7f67b1c284d
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
Default to 4.6, but can overwritten to something else in
prebuilts/gcc/$os/$arch/$arch-linux-android*-$ver
Change-Id: I16f99d642b8ff8e831d392261a0c536041107051
The 4.4.3 TC was still being specified in one spot.
Also, no need to cross-set x86/ARM variables when buliding
for ARM/x86.
Change-Id: Icbb0f772a983a24dc10ccab0800d4b7bbd60a099
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
This should help us support users with build issues.
Given that they inculde the dumpvars in their error report,
we will be able to avoid asking standard questions like
"what version of Ubuntu are you using?"
Change-Id: Ib7c452d805d5e64075a44dc40e41d4605cc1ef4a
"lunch sdk-eng" on cygwin tries to use a gcc.exe from the
prebuild arm toolchain, but it doesn't exist. This prevents
from setting variables to point on a gcc toolchain if there
is none for the given arch.
Change-Id: I3b72220663687f9fdaacc050899aef00632f2c3c
androideabi target is already in upstream GCC. The arm-linux-
androideabi toolchain can be built directly from upstream GCC.
Switching from old special tailored arm-eabi toolchain to the new
arm-linux-androideabi toolchain make us closer to the opensource
community and friendly to all toolchain developers.
kernel still uses arm-eabi toolchain. So we add arm-eabi toolchain
path to PATH.
The arm-linux-androideabi-4.4.x toolchain is built with the same
source as the latest arm-eabi-4.4.3 toolchain except for the
target change patches.
Change-Id: I1e5f2fe2faeee08f913f37e0ba93e84d2654a8ff
Colin Cross