Since we switched to $(HOST_OUT)/lib64 for 64-bit libraries and
$(HOST_OUT)/lib for 32-bit libraries.
Change-Id: Ie43bc03c37e2ac8542412a7543a6af5d60c6f725
We first define TARGET_COPY_OUT_VENDOR as a placeholder. In product
config makefiiles we actually get the placeholders in
PRODUCT_COPY_FILES. A device can set up TARGET_COPY_OUT_VENDOR in its
BoardConfig.mk. We substitute the placeholder with the real
TARGET_COPY_OUT_VENDOR value after loading the BoardConfig.mk.
With this change, we can support building vendor stuff to
system.img (the default) or a separate vendor.img.
Bug: 16515152
Change-Id: I5b601d7a8b34fe032a1bac02aa5c204a3765691d
Set up TARGET_IS_64_BIT and HOST_IS_64_BIT early so we don't need 2
mechanisms to judge if it's 64-bit build;
Remove the unnecessary 32-bit host variables.
Change-Id: I08d6d4d9ea70f91135fe2ee05463fb9a0d1cee42
In 64-bit multilib host build, changed from
32-bit lib: out/host/<platform>/lib32
64-bit lib: out/host/<platform>/lib
to
32-bit lib: out/host/<platform>/lib
64-bit lib: out/host/<platform>/lib64
.
That way the host library path is consistent with the multilib target
build's. Also with this change prebuilt 32-bit libraries can be reused
in 64-bit host build as 2nd arch binaries. (With previous setup, they
can't be used because they have rpath ../lib in it while the 2nd arch
library path needs ../lib32.
Change-Id: I020199d0c7dd52cdc8dcb7d3a1d22cd6178672e1
With multilib host build, the build system installs host
shared libraries to different directories depending on a
library's bitness:
- HOST_OUT_SHARED_LIBRARIES points to the library path of 64-bit;
- 2ND_HOST_OUT_SHARED_LIBRARIES points to the library path of 32-bit;
- If you don't care the bitness of the libraries and just want whatever
version the librareies are built by default, use HOST_LIBRARY_PATH.
Bug:13751317
Change-Id:Id4c818941dc4ea35d795767c76f698529bd6aebb
Also we don't need to force LLVM built from source, for we already force
LLVM to be built as 32-bit.
Bug: 13751317
Change-Id: Ifadf1988d28b60cb06316de50f5bdc1834f1acc0
We already support pure 32-bit and 64-bit-by-default multilib build.
With HOST_PREFER_32_BIT we can build 32-bit-by-default multilib build.
This will be lest disruptive during the period we transition to
64-bit-by-default.
Bug: 13751317
Change-Id: I0d56ce4abbe4afeaacfd70d709f6a349791c0722
This change basically ported our target multilib to the host side.
It supports 2 host build modes: x86 and x86_64 multilib build.
For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64
multilib build. Later we'll default to x86_64 build and have a flag
to force 32-bit only build, which may be needed by SDK build.
In host module definition, like in target ones, you can use the
following
LOCAL variables to set up multilib configuration:
LOCAL_MULTILIB: can be "both", "first", "32" or "64".
It also supports the same set of arch or 32-vs-64 specific LOCAL
variables.
By default, it builds only for the first arch.
To keep path compatibility, in x86_64 build files are still output to
out/host/linux-x86; Both 32-bit and 64-bit executables are in
out/host/linux-86/bin;
In x86_64 build 32-bit shared libraries are installed to
out/host/linux-x86/lib32
and 64-bit shared libraries are installed to out/host/linux-x86/lib;
32-bit object files are output to out/host/linux-x86/obj32 and 64-bit
object files
are output to out/host/linux-x86/obj.
Bug: 13751317
Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
To build oem.img:
- You must define BOARD_OEMIMAGE_PARTITION_SIZE in your BoardConfig.mk
- The file system type will be the same as system.img and userdata.img.
- To install a module to oem.img, use "LOCAL_OEM_MODULE := true"
- run "make -j48 showcommands oem_image dist". By default it's not
built.
Bug: 13367676
Change-Id: I1a26d4d0c61b72ecffe60279667b1b3de050780d
Introduce ro.product.cpu.abilist32 / abilist64, which are
comma separated lists of the 32 and 64 bit ABIs that the
device supports. These properties are used by the zygote and
system server to determine what ABI an app should be
started with.
This changes move abilist related make steps out of envsetup.mk
and into config.mk because they depend on variables set by
core/combo/***. Additionally, config.mk performs a few additional
cleanups of these variables (like stripping them) after the
inclusion of envsetup.mk so this seems like a better place to
put them.
bug: 13647418
Change-Id: I3db39bdd761220c5b4966f651892fb592396f9a1
Add a (read only) system property that is a comma
separated list of ABIs supported by the device in order
of preference. For example, typical arm-v8 device might
define:
ro.cpu.abilist = arm64-v8a,armeabi-v7a,armeabi
For most purposes, a single flattened list like the above is
probably more useful than the parallel system of variables
TARGET_CPU_ABI{2} / TARGET_2ND_ARCH_CPU_ABI{2} that we use
in the build system.
Change-Id: If9102669ad9f5f8fd89a8bcc5bf88cca1acadc3c
* commit '8c89a9ff9cd461e4bc077a91a0c7c32b17a92ebd':
add new gen/ directory for generated sources
warn on LOCAL_MODULE_PATH in multiarch shared libraries
Support LOCAL_MODULE_RELATIVE_PATH
Allow modules to generate source into $OUT/gen, which will then
be copied into $OUT/obj and $OUT/obj_$(TARGET_2ND_ARCH) as
necessary. This allows a single build rule invocation that includes
generated source to build for the first and second architectures.
Modules will need to change calls to local-intermediates-dir into
local-generated-sources-dir.
Change-Id: I62504bad9454b3d9fde7b84ab9f0a487a2ecf0bf
* commit '088319dd22ac4bc65eb284dfeeab368ac2e90ca9':
Add 2nd arch directories for apps
Set up rules to build prebuilts for TARGET_2ND_ARCH
Set up rules to build packages for TARGET_2ND_ARCH
With those variables, you can set up different values for TARGET_ARCH
and TARGET_2ND_ARCH.
Also fixed a couple of variables.
Bug: 11654773
Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b
Conflicts:
core/base_rules.mk
By default, an executable is built for TARGET_ARCH.
To build it for TARGET_2ND_ARCH in a 64bit product, use:
LOCAL_32BIT_ONLY := true
To skip a module for TARGET_2ND_ARCH, use:
LOCAL_NO_2ND_ARCH := true
Bug: 11654773
Change-Id: Ieb293d25b21024bfe1b554044df338e064ac7b46
The rules for the 2nd arch are set up in the second inclusion
of static_library_internal.mk.
libfoo of the 2nd arch will be built into
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/libfoo_intermediates/libfoo.a.
Bug: 11654773
Change-Id: I1d92733968fc442e9225b4df5bd1b551a81d89f7
This is the first step to build 32-bit libraries in a 64-bit product.
It will work like this:
1) In the product's BoardConfig.mk, define:
TARGET_2ND_ARCH, TARGET_2ND_ARCH_VARIANT, TARGET_2ND_CPU_VARIANT.
The build system uses those variables to set up an additional compiler
environment for the second arch.
2) When parsing Android.mks, the build system sets up rules to build a
module for both the 1st arch and the 2nd arch, unless it's explicitly
asked to skip so.
Android.mk will be adapted if there is additional rule of generating
source files.
The build system will accept arch-specific LOCAL_ variables, such as
LOCAL_CFLAGS_arm, LOCAL_CFLAGS_armv7-a-neon, LOCAL_CFLAGS_cortex-a15,
LOCAL_CFLAGS_aarch64 etc. Modules use such variables to set up build for
various archs at the same time.
3) Install binary of the 2nd arch by adding "<module_name>:32" to
PRODUCT_PACKAGES. All 2nd-arch libraries linked in by "<module_name>:32"
will be installed automatically.
Bug: 11654773
Change-Id: I2df63cd5463a07bf5358bee2a109f8fb9590fe30
Conflicts:
core/combo/TARGET_linux-arm.mk
With those variables, you can set up different values for TARGET_ARCH
and TARGET_2ND_ARCH.
Also fixed a couple of variables.
Bug: 11654773
Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b
By default, an executable is built for TARGET_ARCH.
To build it for TARGET_2ND_ARCH in a 64bit product, use:
LOCAL_32BIT_ONLY := true
To skip a module for TARGET_2ND_ARCH, use:
LOCAL_NO_2ND_ARCH := true
Bug: 11654773
Change-Id: Ieb293d25b21024bfe1b554044df338e064ac7b46
The rules for the 2nd arch are set up in the second inclusion
of static_library_internal.mk.
libfoo of the 2nd arch will be built into
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/libfoo_intermediates/libfoo.a.
Bug: 11654773
Change-Id: I1d92733968fc442e9225b4df5bd1b551a81d89f7
This is the first step to build 32-bit libraries in a 64-bit product.
It will work like this:
1) In the product's BoardConfig.mk, define:
TARGET_2ND_ARCH, TARGET_2ND_ARCH_VARIANT, TARGET_2ND_CPU_VARIANT.
The build system uses those variables to set up an additional compiler
environment for the second arch.
2) When parsing Android.mks, the build system sets up rules to build a
module for both the 1st arch and the 2nd arch, unless it's explicitly
asked to skip so.
Android.mk will be adapted if there is additional rule of generating
source files.
The build system will accept arch-specific LOCAL_ variables, such as
LOCAL_CFLAGS_arm, LOCAL_CFLAGS_armv7-a-neon, LOCAL_CFLAGS_cortex-a15,
LOCAL_CFLAGS_aarch64 etc. Modules use such variables to set up build for
various archs at the same time.
3) Install binary of the 2nd arch by adding "<module_name>:32" to
PRODUCT_PACKAGES. All 2nd-arch libraries linked in by "<module_name>:32"
will be installed automatically.
Bug: 11654773
Change-Id: I2df63cd5463a07bf5358bee2a109f8fb9590fe30
/system/lib always contains 32-bit libraries, and /system/lib64 (if
present) always contains 64-bit libraries.
Move things around a little bit, so TARGET_ARCH can be used to define
the build paths.
Bug: 11654773
Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
Bug: 5368571
Now we have a phony target "tests" instead.
The target can be built in any other build variant (eg userdebug).
For example, "make PRODUCT-full-userdebug tests dist" will build and
put the *-test-* zip file in the dist dir.
The "tests" target will include all modules tagged as "tests" in
addition to other modules in specific target out directories.
Change-Id: I8383097380d8e6846c3e2107d6dd5f68788cfc39
It is not forbidden to say LOCAL_MODULE_TAGS := user,
and if you don't say LOCAL_MODULE_TAGS, it now defaults
to optional.
Change-Id: I0a0b200bb6f1c7bf1fe3a89cdc8f69678617526c
So, just add the output include directory to the include path
Change-Id: Ia370454237913a748288124f65a6b731b17d6e1a
Signed-off-by: Dima Zavin <dima@android.com>
Bug: 5769921
With this change, to build factory_ramdisk.img, set
PRODUCT_FACTORY_RAMDISK_MODULES in your product config.
PRODUCT_FACTORY_RAMDISK_MODULES consists of
"<module_name>:<install_path>" pairs.
<install_path> is relative to the root of the factory ramdisk output.
For example:
PRODUCT_FACTORY_RAMDISK_MODULES := \
toolbox:bin/toolbox adbd:sbin/adbd adb:bin/adb
On the other hand you can use PRODUCT_COPY_FILES to copy prebuilt files
to the factory ramdisk.
Or you can define modules that are specific for the factory ramdisk
(with LOCAL_MODULE_PATH pointing to TARGET_FACTORY_RAMDISK_OUT) and add
the module names to PRODUCT_PACKAGES.
Change-Id: I80ff72606415cd74fe6f3bc93020a05d84e45b70
Bug: 5153694
To build cache.img, set BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE (required,
ext4 only for now), BOARD_CACHEIMAGE_PARTITION_SIZE (optional) in
BoardConfig.mk.
Change-Id: I1d8b91646aa1dba88285e008ad3335768bcbddd2
They are relative to PRODUCT_OUT so can be used in PRODUCT_COPY_FILES.
If TARGET_COPY_OUT_VENDOR instead of hardcoded system/vendor is used, we
will be able to transition smoothly to a separate vendor staging directory.
Change-Id: Ia9fdb208768cf4699180306280b4c02421b2ea9c
Merge commit 'bf2ed191fe229b6a83684c19a57e11e7b50c8637'
* commit 'bf2ed191fe229b6a83684c19a57e11e7b50c8637':
Move odex related files to product-specific dir.
Merge commit 'a83940fa7851b35712e559be2246b56b5666b805' into gingerbread-plus-aosp
* commit 'a83940fa7851b35712e559be2246b56b5666b805':
Move odex related files to product-specific dir.
For target Java libraries, now the LOCAL_BUILT_MODULE includes both javalib.jar
and the .odex file, if dexpreopt is enabled.
These 2 files are moved to a product-specific dir in this change.
For target Java Libraries, $(intermediates) now points to the product-specific dir.
There is still a javalib.jar in the $(intermediates.COMMON) dir, which is used as dependency.
Nothing is changed for host Java libraries.
Change-Id: I2546dbb940c74537864ca002d1acb49bb731fbbc
Don't try to do the host build if we're configured for sim-eng. They
seem to be clashing, and it's redundant anyway.
Change-Id: I8e1a24b6e07d28701b32b6559ba39337b211264d
Merge commit '77070aa757806d1617d707db4d2bd7931b2353fc'
* commit '77070aa757806d1617d707db4d2bd7931b2353fc':
Turn dalvikvm host builds on by default when linux is the host OS.
Merge commit 'ce7d5023c3df4c16ae395d64d51dd8345e40a39e' into gingerbread-plus-aosp
* commit 'ce7d5023c3df4c16ae395d64d51dd8345e40a39e':
Turn dalvikvm host builds on by default when linux is the host OS.
Previously host builds were only enabled under user and user-debug
builds. This will make it easier for Androids to find out if they've
inadvertently broken host compatibility in native code.
Change-Id: Id1f2d5e189c4c1b6462fe03bab1b0f75e98a599c
With the CL, "include $(BUILD_NATIVE_TEST)" to build native test;
"include $(BUILD_HOST_NATIVE_TEST)" to build a host native test.
Change-Id: Icdbbcf906cd4c5c35e65962897490052cd051102
The path to the Java toolchain is now explicitly
specified so no manual configuration should be
required.
Change-Id: I84abc122c557372e77e4579e9a9efe56af2b412c
The java version changed, and we made envsetup automatically find the right JAVA_HOME.
This change forces everyone to re-source envsetup.sh
Change-Id: Ieb9512d5725cca26a83debf9b0480bc20e19d5ee
Fix javadoc for Java 6.
If you don't set bootclasspath, there would be errors like:
javadoc: error - In doclet class DroidDoc, method start has thrown an exception java.lang.reflect.InvocationTargetException
Change-Id: I1b83360cb595d50577c6043d6e91b0f92e4c04d6
Avoid inheriting PRIVATE_BOOTCLASSPATH from moduels that depend on api-stubs-timestamp
The inherited value has caused build breakage on Mac build.
Change-Id: I8a1b1d6c6d411f6aaaee2d8dbd0297e3d60ab5c2
Ignore STAY_OFF_MY_LAWN when setting JAVA_HOME.
Don't check STAY_OFF_MY_LAWN in set_java_home. That function already
refuses to update JAVA_HOME if it's set to something, which should
be sufficient for anybody who doesn't want the script to mess with it.
With this change, you can get the benefits of the 1.5/1.6 auto-selection
without having to suffer through window title changes.
Change-Id: I5cfc5d6fdf26a10b42b52925f877012c0506b9a5
gcc-4.4.3 toolchain is based on fsf GCC-4.4.3 with numerous patches.
It reduces 3.65% code size than the prebuilt gcc-4.4.0 toolchain,
and improves 3.4% performance on Android benchmarks.
The toolchain uses gold as default linker. With gold, the toolchain
further reduces 1MB system image.
Change-Id: I55eb4df185f2932e71498fcc28428e4d1b175393
- envsetup.mk & config.mk: we define a new BUILD_OS and a minimal set
of things like BUILD_OUT to be able to use some local tools when
doing cross-compilation. This allows us to use the Linux version of
ACP when cross-compiling the tools to Windows.
- Makfile: include windows_sdk.mk when needed to build a Windows SDK.
- main.mk: support a win_sdk target (e.g. PRODUCT-sdk-win_sdk)
(Merge master Change I9d08d0df)
The WebKit library link line is exceeding 128KB on sim-eng builds.
The path to sim-eng object files is slightly longer than device builds
because the object files live under the "host" directory.
This change truncates the "product" directory name to "pr", reducing the
command line by a few KB. This only affects sim-eng builds.
The real fix will need be to webkit (see internal bug 1917987), which
will eventually start failing on device builds if it continues to grow.
Original change by joeo@abreu on 2009/04/06 19:54:13.
Implement SDK add-ons in the build system.
- Add an option to use the standard javadoc doclet instead
of droiddoc, since droiddocs non-sdk templates aren't
ready for prime time.
- Add the notion of a stubs for a library. It's only
implemented for java libraries, but when we do native
libraries in the NDK or sdk-addons, it will work there too.
Original author: joeo
Merged from: //branches/cupcake/...
Automated import of CL 145618
