Use a temporary variable my_checked_module instead,
so that we don't override the 2nd_arch's checked module with the
1st_arch's in multilib build.
Note that by default we checkbuild 2nd_arch only for host modules,
but not for target modules.
We enable multlib for target modules by default, it would take too
much time to checkbuild for both archs. For 32-bit modules actually we
can checkbuild a 32-bit product.
Change-Id: I0a5ba75699225b7641442673483731a8fd360d61
Some packages can override list of locales with
LOCAL_AAPT_INCLUDE_ALL_RESOURCES parameter, disabling
pseudolocalization. Adding new --pseudo-localize flag to
aapt if pseudo-locales are specified in product locales
list solves this issue.
Change-Id: Iae705d4fe99453650339fd1ca65d1005671b3e4f
- This simplifies the logic to get the mapping of built-file to
installed-file. Previously we used file suffix matching which is error
prone and not scalable.
- With this change the .odex files will be included automatically.
Bug: 13585955
Change-Id: I4599abf93b9d501bac7aca7758d7f3aee21b3e36
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
With this change, you can package up modules while avoiding installing
them to the system.img or userdata.img.
- build/core/tasks/tools/package-modules.mk
You can use this template to package up modules into a zip file and
preserve the installed file paths.
- LOCAL_PICKUP_FILES, you can use this variable to package up extra
files/directories.
Bug: 13585955
Change-Id: I103042b24ccf17cf5dc90c016d97ed1dd293e50b
LGPL projects need their source code distributed under very
similar conditions to GPL and MPL, the only difference is the
conditions under which they may be linked. It makes sense to
include them in the GPL archive tarballs.
Change-Id: I2c2df03906bfeee55566102aa688e4cdc283700b
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Some executables will need to be built for both 32-bit and 64-bit.
For linker/linker64, debuggerd/debuggerd64, and a few more, they
will be installed in the same path (/system/bin), but with different
filenames. Allow the module to specify LOCAL_MODULE_STEM_32 and
LOCAL_MODULE_STEM_64 to name the two versions.
Change-Id: I573e8678c7332245a064f31246be0a05f0a9e25f
Some executables will need to be built for both 32-bit and 64-bit.
For tests, it will be convienient to keep the name of the executable
the same, but install them in a different location. Add
LOCAL_MODULE_PATH_32 and LOCAL_MODULE_PATH_64 to allow a module
to specify different paths for 32-bit and 64-bit executables.
Change-Id: I3be830e899c6d485fe55c25c66b20b3fe64c795e
-- Added TARGET_PREFER_32_BIT, which sets LOCAL_32_BIT_ONLY for an
executable, if LOCAL_NO_2ND_ARCH is not true.
Name resolving in 64-bit multilib build:
-- Name resolving in PRODUCT_PACKAGES:
foo:32 resolves to foo_32;
foo:64 resolves to foo;
foo resolves to both foo and foo_32 (if foo_32 is defined).
-- Name resolving for LOCAL_REQUIRED_MODULES:
If a module is built for 2nd arch, its required module resolves to
32-bit variant, if it exits;
Otherwise for executable and shared library, a required module
resolves to the default 64-bit variant; for other module classes,
required module foo resolves to both foo and foo_32 (if foo_32 is
defined)
Bug: 12898862
Change-Id: I5fda1a77f58814097b10b5ad2743ee25adfaecc4
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
Most users of LOCAL_MODULE_PATH are setting a subdirectory of the
normal install path, for example to install HALs into system/lib/hw.
This is problematic for multiarch builds, where the install location
depends on the arch. Allow modules to specify LOCAL_MODULE_RELATIVE_PATH.
HALs will generally use:
LOCAL_MODULE_RELATIVE_PATH := hw
Change-Id: I4e4ceec61d026bbe74ba604554c06104bde42e5e
Print the name of the module that is providing an unhandled install
path.
Change-Id: I0e8b02f01de1dde715f0985034ad943f793218ba
Conflicts:
core/base_rules.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
Conflicts:
core/base_rules.mk
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
We currently have two types of host libraries, those
meant for the host VM (Sun, OpenJDK etc.) and those meant
for a host dalvik build. The former need to be compiled
against the host standard libraries and the latter need
to be compiled against libcore. This change introduces
two new build rules to complement the existing the existing
host rules.
BUILD_HOST_DALVIK_JAVA_LIBRARY : Build a java library for
a host build of dalvik. Bootclasspath will be set to a host
build of libcore.
BUILD_HOST_DALVIK_STATIC_JAVA_LIBRARY : Build a static java
library for a host build of dalvik. Bootclasspath will be set
to a host build of libcore.
This change also removes support for the LOCAL_BUILD_HOST_DEX
flag, which is now unnecessary.
bug: 8992787
(cherry picked from commit 0dd273a3f6)
Change-Id: I3569fff8eaa4d26d55fcc317bd98471f55d74c14
only if the module is built against the platform, not the SDK.
Previously it added it if it's doing a platform build.
But we can do an apps_only build inside the platform source tree and
such a build may build modules against the platform.
This fixes the apps build in the platform source tree.
Change-Id: I73e32a8f0e505349790a102321f88e77fba472cd
With this change, you can install a shared library with module name foo
as bar.so to the system.img with:
LOCAL_INSTALLED_MODULE_STEM := bar.so
Note that we in general still disallow a static/shared library to
specify LOCAL_MODULE_STEM or LOCAL_BUILT_MODULE_STEM, because the build
system uses LOCAL_MODULE to compute build time dependencies, such as
export_includes, the -l linker flag etc.
Also, if you use LOCAL_INSTALLED_MODULE_STEM to change the installed
file name and if any other module links against this library, you may
run into runtime error: the library name baked in to the binary is not
the same as file name in the system image.
Change-Id: I55b571c8139c3bda07a4a0e50cea0f20d8d6c168
With this change, use:
* LOCAL_PROGUARD_ENABLED := obfuscation # to enable obfuscation
* LOCAL_PROGUARD_ENABLED := optimization # to enable optimization
* LOCAL_PROGUARD_ENABLED := obfuscation optimization # to enable both
Now the meaning of the LOCAL_PROGUARD_ENABLED options:
* full:
Use the build system's default configurations:
with shrink but no obfuscation or optimization,
global proguard flags in build/core/proguard.flags
are applied.
* custom:
The same as "full" except no aapt-generated resource-related
proguard flags.
* nosystem:
Don't use any build system's default configurations; but
aapt-generated proguard flags are still applied. You are
responsible for any other flags.
* disabled:
Disable proguard.
* obfuscation:
The same as "full" but with obfuscation enabled.
* optimization:
The same as "full" but with optimization enabled.
* no value (the default):
The build system chooses the proper value: "full" if it's an
app; "disabled" if it's a library.
You can use more than 1 of them in a meaningful combination,
for example:
LOCAL_PROGUARD_ENABLED := obfuscation optimization
Bug: 10307372
Change-Id: Id248caca3048e99547f16559fae74f4afe85c354
This reverts commit 28b46fc16c.
Speculative fix for master builds. I cannot repro the break the bots
are seeing locally, but it seems related to building protobufs and this
CL was in the first broken build.
Also source files which have dependencies need to be bundled together
(at least the way the build system is set up now). Move
--proto_path=$(TOP) to the end so that it does not take precedence
over user-supplied --proto_path flags.
Change-Id: Ia532647fe8811d39230a23ba3671685b0388cbe0
$(built_odex) depends on $(LOCAL_BUILT_MODULE) but doesn't have any build
recipe. It is built by the rules of $(LOCAL_BUILT_MODULE) that results in
a subtle bug: $(built_odex) is always newer than $(LOCAL_BUILT_MODULE)
if $(LOCAL_BUILT_MODULE) rebuilt. Therefore 'make' thinks the targets
(/system/app/$app.odex) depending on $(built_odex) don't need to be updated.
It seems an allegedly optimization bug of 'make'.
The simple fix is to explicitly add $(LOCAL_BUILT_MODULE) as a dependency
of $(installed_odex).
