- Deleted unused functions in definitions.mk.
- lint is never fully functional in the platform source tree.
- Retire LOCAL_DIST_BUNDLED_BINARIES: now the build system/framework
supports JNI embedded in apk.
Change-Id: I6314cb20d1544c704ccbc4c1f9cccb9c54fb5a51
Using $(BUILD_NUMBER) inside a rule causes odd behavior, as the rule
is different every time make is run, but since make doesn't depend
on the command line it only ends up being built with the new value
if some other dependency has changed.
To allow ninja, which does depend on the command line, to provide the
same behavior, store the build number in out/build_number.txt, and
use a shell expansion to cat the file in rules that use it. This will
cause the rule command to stay identical between builds, while still
getting the new build number if the rule is rerun for a dependency.
Also use the same trick for BUILD_FINGERPRINT, and the date in
droiddoc rules.
Change-Id: I6c5e6b6b3ef4c613563d7f5604df0e401575ba5f
Move the @echo command that prints the rule description to be the
first command in each rule so that the kati tool can find it to
use as a ninja rule description.
Change-Id: I90f27c35bb719d327a7f2109f8d00d3589082f19
Don't uncompress/page-align the jni libraries in apps_only build,
because the apk may be run on older platforms that don't support loading
jni directly from apk.
When prebuilt apks are installed to platform build, the build system
will automatically uncompress/page-align the prebuit apks in M and
downstream, so no need to uncompress/page-align in the apps_only build
either.
Bug: 22491084
Change-Id: I67e977b2592800ae467450592069843b4e5fc466
Another change in bionic/linker adds linker_asan/linker_asan64 that
know where to find ASan shared libraries.
Also, include linker_asan to the required packages list when building
for ASan.
Change-Id: I8ebe7c0091bbeb0c135708a891d33d9844373d37
Clang is really aggressive at optimizing a handful of cases (read:
clang will ruin your day some if you write bad code). Fortunately, it
also emits a warning when it's about to do this.
To prevent anyone from suffering from these optimizations, make these
warnings errors and make them impossible to disable.
Change-Id: I5e10bb0fc2ca23190017da716b3b84635577a0bd
Prevents aapt from generating java symbols for strings that don't have
a default localization.
Bug: 21537397
Change-Id: I2f17397e33d823045f7dcff02e3d0817f3f81849
These directories are excluded in addition to OUT_DIR.
This can be useful if your build system has other output directories
beyond what OUT_DIR is set to.
Change-Id: I6d98a85bcc8c89279e939406a7fec32547e8922f
- We don't need LOCAL_PAGE_ALIGN_JNI_SHARED_LIBRARIES now, for we always
page-align jni shared libraries and store them umcompressed.
- For prebuilt apks, we don't extract jni any more; Instead we always run
uncompress-shared-libs on them.
- For apks built from source, we still install the jni separately, because
that way multiple apks can share the same jni and it saves space.
With this change, for most prebuilt apks, we don't need to specify
LOCAL_PREBUILT_JNI_LIBS ("@lib/<abi>/foo.so") any more, for the build
system automatically replaces the embedded jni with uncompressed files;
But if a prebuilt is a fat apk (i.e. containing jni not needed by the
current product architecture), you still need LOCAL_PREBUILT_JNI_LIBS to
specify what jni to keep. Otherwise all embedded jni will be replaced with
uncompressed files, that wastes space.
Bug: 8076853
Change-Id: Ic3666dc72bf17cd293787414dd185470b365f967
Normally the binaries use the exsiting $ORIGIN/../lib[64] with binaries
in the bin subdirectory;
For historical reason the binaries in the SDK package don't have a bin
subdirectory. This workaround enables them to work in the existing SDK
directory structure.
Bug: 21301578
Change-Id: Ibebfbfb8b30e81e7bbaf13a21bb205f3f0282d24
(cherry-pick from commit 4fe7bfd373)
Normally the binaries use the exsiting $ORIGIN/../lib[64] with binaries
in the bin subdirectory;
For historical reason the binaries in the SDK package don't have a bin
subdirectory. This workaround enables them to work in the exsiting SDK
directory structure.
Bug: 21301578
Change-Id: Ibebfbfb8b30e81e7bbaf13a21bb205f3f0282d24
This allows to compile dex targeted java sources using Jack and Jill.
Default is still to compile with the legacy toolchain. Default can be
switched to the new toolchain by setting environement variable:
export ANDROID_COMPILE_WITH_JACK=true
Toolchain can also be forced for one module by defining
LOCAL_JACK_ENABLED:=full # disabled, full, incremental
in the mk portion defining the module.
Jack execution environement can be controlled with:
Global variable ANDROID_JACK_VM allow to change the jvm executing Jack.
Global variable ANDROID_JACK_VM_ARGS allows to change default args given
to the jvm.
Global variable ANDROID_JACK_EXTRA_ARGS allows to define some default args
to give to Jack
LOCAL_JACK_VM_ARGS allows to override default args given to the jvm for
the module.
LOCAL_JACK_EXTRA_ARGS allows to override default args passed to Jack.
This includes cherry-picks of the following changes:
b4c49cba5722c3fa6d73138768c1bb5dd3e1d31283d5d040478bc90fd2d6140274707e0fbc9ff2a2833b427d72f9a27f45b4280966694137822c443dc6b44d43c3d2a76c14bf06744f60fc95573d5036b8213916142794e7b582801f2c44d0c76d99dca1f528e132d676a5e0bd1ae25b3984ff Partially, only Jack related parts werekept
ec46a3b71fabee3a9f4177cbe10fd9daf07db4cdb6bfb5893a
Ie all Jack related changes untill
b6bfb5893a
except
a96cc59ab5 "Use Jack by default"
Change-Id: If9d47ef1c4fd1e6765ad2a47d816c1ad3cfab0e3
- Detect java-source-list before transforming to java-source-list-uniq.
This fixes non-fatal errors in build log like:
/bin/bash:
out/target/common/obj/APPS/android.core.tests.libcore.package.tzdata_intermediates/classes/java-source-list:
No such file or directory
- Cleaned the outdated incrementaljavac. Nobody is using this feature
and now we switched to jack.
Change-Id: If1adb9b5820d9b295a11984c0f170f9a7ff4de7b
- We don't need LOCAL_PAGE_ALIGN_JNI_SHARED_LIBRARIES now, for we always
page-align jni shared libraries and store them umcompressed.
- For prebuilt apks, we don't extract jni any more; Instead we always run
uncompress-shared-libs on them.
- For apks built from source, we still install the jni separately, because
that way multiple apks can share the same jni and it saves space.
With this change, for most prebuilt apks, we don't need to specify
LOCAL_PREBUILT_JNI_LIBS ("@lib/<abi>/foo.so") any more, for the build
system automatically replaces the embedded jni with uncompressed files;
But if a prebuilt is a fat apk (i.e. containing jni not needed by the
current product architecture), you still need LOCAL_PREBUILT_JNI_LIBS to
specify what jni to keep. Otherwise all embedded jni will be replaced with
uncompressed files, that wastes space.
Bug: 8076853
Change-Id: Icf07e0998ac3602e6e05e80fed836fbafca33e01
Add replocation-packer step for dynmic executables.
Enable it by default for arm and arm64 platforms.
Bug: http://b/18051137
Change-Id: I0c88fd31595bcea62a087f219acb9ecf9c80f2e5
If a prebuilt APK contains shared libraries and the flag
LOCAL_PAGE_ALIGN_JNI_SHARED_LIBRARIES := true is set, then
uncompress any shared libraries stored within the APK.
This allows processes to load the shared library directly from
the APK.
Bug: 20247329
Bug: 8076853
Bug: 1162500
Change-Id: Iac4db32457d9ce31eb7256410023819b44fda0a6
With this, you can easily add more executables, jars or shared libraries
to the package. Also now it automatically takes care of
32-bit-v.s.-64-bit library issue.
Change-Id: I5afe00fadc978d0da229b192eca1a4b1c149764e
Strip prebuilt shared library but not try adding gnu debuglink.
It would fail if you try run the adding gnu debuglink command if a
prebuilt is already stripped.
Bug: 17177288
Change-Id: If5811865715c2437e45fbd329983ef1212ef0109
(cherry picked from commit bfb52a2ec1)
There will be two version of the the nanopb-c library,
libnanopb-c-2.8.0 which doesn't support automatic malloc
and libnanopb-c-2.8.0-enable_malloc which does.
There will be two version of the the nanopb-c library,
libnanopb-c-2.8.0 which doesn't support automatic malloc
and libnanopb-c-2.8.0-enable_malloc which does.
Set LOCAL_PROTO_OPTIMIZE_TYPE=nanopb-c which doesn't support
malloc and set it to nanopb-c-enable_malloc which does.
For client code details see nanopb-api:
http://koti.kapsi.fi/jpa/nanopb/docs/reference.html
Change-Id: If238412463aabb5e1d556dfc9c464bcaf9e3333a
Previously when a file in LOCAL_SRC_FILES starts with "../", the object
file may escape out of the module's intermediate directory, because we
insert the source file's path (but not with LOCAL_PATH) to the object
file's path. Even worse when two object files escape to the same destination
and cause conflict.
This change fixes the issue by removing the "../" inside the object
files' paths. To do that, we have to set up the compilation rules for
those files one by one, instead of using the one-for-all static
pattern rules.
Bug: 19641115
Change-Id: I19f3c48ece3244fa14acb2caa609deea710840d3
We should put the NDK library path before
$(TARGET_OUT_INTERMEDIATE_LIBRARIES), so that we link against the NDK
libc/libm, instead of the platform libc/libm in
$(TARGET_OUT_INTERMEDIATE_LIBRARIES), which may still being written out,
because we don't have dependency on them.
Bug: 19613709
Change-Id: I26a8b272e38b7436bca3324246b21cd71349662b
Previously we store tag's installed modules in a separate variable
ALL_MODULE_TAGS.$(tag). However we only record the main installed file
for a module, but omit affiliated files like .odex.
With this change, we handle the tagged module the same way as modules in
PRODUCT_PACKAGES.
Change-Id: I7972528a4df5a4ba8bc98930864da9672d32d7fe
Previously if user has a directory with name dummy in the root of the
source tree, "zip -qd package.apk dummy" fails with:
"zip error: Nothing to do!".
This change mitigates the error.
Change-Id: I642e3bf0378e5b9911a068ecb72f795b3e92f1fe
- Add a new flag to zipalign (-p) that page aligns shared
libraries (zip entries ending with ".so") in the archive.
- Add a new build variable LOCAL_PAGE_ALIGN_SHARED_LIBRARIES
to turn on this behaviour in zipalign.
- Add a new LOCAL_JNI_SHARED_LIBRARIES_ZIP_OPTIONS to control
zip behaviour.
Bug: 8076853
Bug: 19330157
Co-Authored-By: Simon Baldwin <simonb@google.com>
Co-Authored-By: Dimitry Ivanov <dimitry@google.com>
Change-Id: I1aa2c039bb2a590ae72f256acc9ba5401c2c59b1
These CFLAGS and CPPFLAGS will always be added last, and are
controlled by the build system. This way we can add warnings that
users are not allowed to disable.
Change-Id: Id71f69249078f62ca2687ecbf764aff0fd3a1c1b
Each module may engage Jack incremental with
LOCAL_JACK_ENABLED := incremental
Include renaming of LOCAL_USE_JACK to LOCAL_JACK_ENABLED that is
now accepting 3 values "disabled", "full" and "incremental".
Change-Id: Icbff275b397bee36b29312e821f3e8d45f83fbcc
Normally the build function initialize-package-file will delete all
class files and all directory entries from JAR files, but sometimes
external projects (eg. ICU4J) depend on having directory entries in
their JAR files.
This change adds the flag LOCAL_DONT_DELETE_JAR_DIRS (analogous to the
flag LOCAL_DONT_DELETE_JAR_META_INF) which when set will skip deletion
of directory entries in initialize-package-file.
Change-Id: I4464b947b7528fca23925affa95e4071915f04d4
Don't remember why I didn't enable this for the host when I made the
first pass, but it works just fine.
Change-Id: I0892c0bc353bf8b60b432ba9f69f97281177d41d
Clang driver needs -static flag, not -Bstatic,
to produce statically linked modules.
However, -static is not added if LDFLAGS contains -shared,
which is used in bionic/linker to create a shared object with static libraries.
BUG: 18008984
Change-Id: I75c3e24973ee77170285ec4c8e7aacc345722685
Previously for hostdex Java libraries, we set up dependency on only
javalib.jar, which in turn is dependent on classes.jar.
But when jack is enabled there is no dependency of javalib.jar on
classes.jar. In commit b4c49cba57 classes.jar was universally added to
all host java library dependencies. That's unnecessary.
This change adds explicit dependency on classes.jar only for hostdex
modules.
On the other hand, if we switch checked module to $(full_classes_jack),
like what we did in commit 8bc90fd2d6, we won't need this to fix jack
build either, because classes.jar isn't needed when you run checkbuild.
Change-Id: I92c0e4d621d266f6e6914ab2b4f20e5531af070f
Before this change, Java resources are added as a separate step
(add-java-resources-to-package) after dex is run, so jarjar isn't run on
the resource files.
With this change, we add Java resources immediately after we call javac,
so jarjar is run on the resource files (the module's own resource, as
well as resources carried by static Java libraries).
When we generate the final apk/jar, we use the jarjar'ed jar as the
inital pacakge file, with class files and empty folders removed.
(cherry-picked from commit 140274707e)
Bug: 18837479
Change-Id: I15ecf282bfb65fd53dd03fbd03dd4c71927c186a
Before this change, Java resources are added as a separate step
(add-java-resources-to-package) after dex is run, so jarjar isn't run on
the resource files.
With this change, we add Java resources immediately after we call javac,
so jarjar is run on the resource files (the module's own resource, as
well as resources carried by static Java libraries).
When we generate the final apk/jar, we use the jarjar'ed jar as the
inital pacakge file, with class files and empty folders removed.
When jack is enabled, in jack-java-to-dex we add the Java resources to
a temp jar using the PRIVATE_EXTRA_JAR_ARGS, and extrac the files in a
temp dir. Jack will process the resource files and output the result to
PRIVATE_JACK_INTERMEDIATES_DIR. When we package the final apk/jar, we
need to call add-carried-jack-resources to readd the resources.
(TODO: if jack can output all resources to a jar/zip file, we can use
that file as the initial package file as well.)
Bug: 18837479
Change-Id: I8d7296e30ec8d005054cf04c4f2aed6d7a0d823b
Before this change, Java resources are added as a separate step
(add-java-resources-to-package) after dex is run, so jarjar isn't run on
the resource files.
With this change, we add Java resources immediately after we call javac,
so jarjar is run on the resource files (the module's own resource, as
well as resources carried by static Java libraries).
When we generate the final apk/jar, we use the jarjar'ed jar as the
inital pacakge file, with class files and empty folders removed.
When jack is enabled, in jack-java-to-dex we add the Java resources to
a temp jar using the PRIVATE_EXTRA_JAR_ARGS, and extrac the files in a
temp dir. Jack will process the resource files and output the result to
PRIVATE_JACK_INTERMEDIATES_DIR. When we package the final apk/jar, we
need to call add-carried-jack-resources to readd the resources.
(TODO: if jack can output all resources to a jar/zip file, we can use
that file as the initial package file as well.)
Bug: 18837479
Change-Id: I15ecf282bfb65fd53dd03fbd03dd4c71927c186a
java-to-jack is not manipulating jar files, just zip files so there
are no META-INF files generated by jar in them and no reason to filter
them out. And mainly, there are valid META-INF resources in the tree
we must keep.
Bug: 8287658
Bug: 18901198
Change-Id: Ice0fafca686b8fa3bafd886076946fbb1f952fb6
If LOCAL_WHOLE_STATIC_LIBRARIES contains a library that has
two files that have the same name but are in different
directories, only the first gets included.
This fix detects this case, and uses the m option to ar to force the
duplicate object to the end of the archive. After this, using the p
option gets the correct object file.
Change-Id: I2e183f48cef3c79499d4ab8ff147444611ff938b
Includes cherry-picks of:
2e78d2f4263bc7c0f90d58af7014017f16aa3ce6 Jack option --import-res was renamed --import-resource
fdc913ee86fe0c45581178b901a673fdd7937e03 Update references to Jack type collison policy
8d83d1b21ec678fb9fb1c6ee643ace46d5f700ce Rename jill tmp file
8a1c98ce4ba0b4db39f274d6258b6a08bbc3ec2c Ensure that jar-arg-list is never shared
8d83d1b21ec678fb9fb1c6ee643ace46d5f700ce Remove manipulations of jack libraries
Change-Id: I3ee159d408ba5281ac15c9836dc4fd2bdeb845d3
This allows to compile dex targeted java sources using Jack and Jill.
Default is still to compile with the legacy toolchain. Default can be
switched to the new toolchain by setting environement variable:
export ANDROID_COMPILE_WITH_JACK=true
Toolchain can also be forced for one module by defining
LOCAL_USE_JACK:=true # false
in the mk portion defining the module.
Jack execution environement can be controlled with:
Global variable ANDROID_JACK_VM allow to change the jvm executing Jack.
Global variable ANDROID_JACK_VM_ARGS allows to change default args given
to the jvm.
Global variable ANDROID_JACK_EXTRA_ARGS allows to define some default args
to give to Jack
LOCAL_JACK_VM_ARGS allows to override default args given to the jvm for
the module.
LOCAL_JACK_EXTRA_ARGS allows to override default args passed to Jack.
Change-Id: Ib81a0fd5f86a51d1e0edbb81cc791d828a05dd29
This will be necessary to support -std=gnu99 mode for clang 3.6, which
defaults to C11 mode (unlike prior releases that use C99).
Change-Id: Iea84582f9f12ba76b988463cbc0a20bd61042538
This caused a lot of failures in the libc++ tests, since linking
libgcc.a before libc++.so means that the wrong unwinder will be used.
This patch is still correct, but I will revert for now while I find a
good way to apply it without breaking unwinding.
This reverts commit 741b36e922.
Change-Id: I57e0b89534adf5c1677dbf2f64ac750e74bd5fbf
Previously we store tag's installed modules in a separate variable
ALL_MODULE_TAGS.$(tag). However we only record the main installed file
for a module, but omit affiliated files like .odex.
With this change, we handle the tagged module the same way as modules in
PRODUCT_PACKAGES.
Change-Id: I7972528a4df5a4ba8bc98930864da9672d32d7fe
The previous position of libgcc.a/libatomic.a on the link line causes
the linker to prefer satisfying dependencies from these libraries from
other libraries that might include them, rather than from libgcc.a (or
libatomic.a) itself. This imposes an ABI requirement that those
intermediate shared libraries _always_ export those symbols, which is
undesirable.
Change-Id: Ib593236b475d3e98356b2b1be6f96cee2b67378f
Previously, there was one generic definition for each of the
transform-o-to-* functions in definitions.mk, and one target specific
one in each combo/TARGET_*.mk. The generic one was entirely unused,
and the target specific ones were all nearly identical.
Changing anything in these functions was tedious at best, and often
error prone. The differences between any 32-bit arch and its 64-bit
equivalent were restricted to the name of the linker, and the ARM and
MIPS definitions were identical. The few differences between ARM and
x86 looked to be compatibility for an old (ca. 2008) toolchain issue
with --gc-sections, and a bug (LDFLAGS coming first rather than
later).
To simplify things, I've moved the definitions for these out of
combo/TARGET_*.mk and back into definitions.mk. The differences
between ARM and x86 have been scrapped. Anything that really does
still need to be target specific can be handled as I have the linker:
add a TARGET_FOO variable to the given target and then add it to the
generic definition.
Change-Id: I54dc1bffc32ac39f27f0b87247dd6a6dbaf0b162
build/core/Makefile looks for build tasks in either device/*/build/tasks
or vendor/*/build/tasks. Do the same with vendor-specific definitions.mk.
Change-Id: Ib4fd00a1d0effe8e347382a922da101ce26bf696
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Bug: 14416410
Our linker uses "start" as the primary entry point, so we need to adjust this
for mingw-based Windows compiles, or nothing will execute correctly.
Change-Id: I6e99f43e075ef9f00500099ce34ec4425c996454
So result of get-prebuilt-src-arch can be passed to
LOCAL_MODULE_TARGET_ARCH, which takes empty string as "any" actually.
Change-Id: I916c9738ccce4a94ac084fb4141d54659e896a1f
Strip prebuilt shared library but not try adding gnu debuglink.
It would fail if you try run the adding gnu debuglink command if a
prebuilt is already stripped.
Bug: 17177288
Change-Id: If5811865715c2437e45fbd329983ef1212ef0109
Improves performance for LOCAL_WHOLE_STATIC_LIBS by copying the first .a
to the new .a rather than extracting and recreating
Change-Id: Iecdb5e4bb2ce987bb41a70c3393d18a6d72ae689
This fixes mips unbundled build since we switched to mips64el toolchain
for both mips and mips64.
TODO: multilib build support.
Change-Id: I7add92d2cecfc3ab739785ceef6700240a25093a
This fixes mips unbundled build since we switched to mips64el toolchain
for both mips and mips64.
TODO: multilib build support.
Change-Id: I7add92d2cecfc3ab739785ceef6700240a25093a
We've been using -fPIC and -fPIE together in the global cflags all this
time. These options are incompatible. The only reason we haven't been
hit by this before is because of the forced -Bsymbolic in GCC. To fix
this, pass -fpic when compiling objects for shared libraries and -fpie
when compiling objects for executables. For static libraries, also use
-fpic. We have to do this because static libraries might be included in
either a shared library or an executable. Code compiled with -fpie
cannot be included in a shared library, but code compiled with -fpic
may be included in an executable.
We've also been using -fpic and -fPIC together. These are different
options, and only the latter will take effect.
http://stackoverflow.com/a/967010
The final thing this fixes is that we had -f(PIC|PIE) flags being passed
to link commands. These are compile time flags, and don't do anything at
link time.
Bug: 16823325
Change-Id: Ic76f47e63dc2c81b7e1a8058bae1b3dc8565d606
(cherry picked from commit 4803ce2696)
We've been using -fPIC and -fPIE together in the global cflags all this
time. These options are incompatible. The only reason we haven't been
hit by this before is because of the forced -Bsymbolic in GCC. To fix
this, pass -fpic when compiling objects for shared libraries and -fpie
when compiling objects for executables. For static libraries, also use
-fpic. We have to do this because static libraries might be included in
either a shared library or an executable. Code compiled with -fpie
cannot be included in a shared library, but code compiled with -fpic
may be included in an executable.
We've also been using -fpic and -fPIC together. These are different
options, and only the latter will take effect.
http://stackoverflow.com/a/967010
The final thing this fixes is that we had -f(PIC|PIE) flags being passed
to link commands. These are compile time flags, and don't do anything at
link time.
Bug: 16823325
Change-Id: Ic76f47e63dc2c81b7e1a8058bae1b3dc8565d606
- Better messaging if the expected split apk isn't generated by the aapt
command in the base apk rule; Remove the built base apk, so make will
rerun aapt after the user changes the splitting parameters.
- Use cleaner static pattern rules instead of running $(foreach) with
$(eval).
Bug: 16319961
Change-Id: If6ae302e1a39d2e0db8f784d4e1cf292ec855281
Support LOCAL_PACKAGE_SPLITS, which accepts a list of resource lables
and generates multiple apks. The build system sets up rules to sign and
zipalign the split apks.
Bug: 16319961
Change-Id: I344b3d1c7eb158c6d0df879093d666a89870aadd
Apk's path is changed to <parent_dir>/MyApp/MyApp.apk;
JNI path is changed to <parent_dir>/MyApp/lib/<arch_name>/libfoo.so.
Symlinks of JNIs are changed accordingly.
Bug: 16319961
Change-Id: Ib3b2309c95fa9aea27837fcc29e28d990b04747b
Dx is now capable of generating multiple dex file in one run.
This capability is not compatible with --output=*.dex so this CL
changes the --output argument to be a directory. This CL also
includes the packaging of the multiple dex files when dx generates
more than one dex file.
(cherry picked from commit 8ffe9c3e79)
Conflicts:
core/java.mk
Change-Id: I1ddc91b416de5929d4d4b41824c6012b32f94deb
Use "LOCAL_MULTILIB := both" to install jni libraries of both archs in
multilib build.
The build system will package jni of both archs to the apk, or install
them to the right location on the system image and create symlinks,
extract .so files from prebuilt apk, etc if appropriate.
Bug: 15849902
Change-Id: I7e147b5a47db476584c38250de7b36c75ea40d81
- Remove the incorrectly used (and unused) 3rd arg to assert-max-image-size
- Remove test for fstype in assert-max-file-size() as it was always
set to a value leading to 0.
Change-Id: I0a1182fcc85c6c3801d45731e691b9bb38657606
Signed-off-by: JP Abgrall <jpa@google.com>
Previously we only expanded product_MODULES with LOCAL_REQUIRED_MODULES,
but not modules introduced by LOCAL_SHARED_LIBRARIES; Later we did a further
shared libary expansion in vendor_module_check.mk.
It couldn't track C in the following case:
A : B, by LOCAL_SHARED_LIBRARIES; B : C, by LOCAL_REQUIRED_MODULES.
With this change, we transformed the LOCAL_SHARED_LIBRARIES dependencies
into LOCAL_REQUIRED_MODULES dependencies before doing the required
module expansion and the loophole is closed.
All module names are now expanded to product_MODULES now and it makes
vendor_module_check.mk simpler.
Change-Id: I8835a478d2ce0ce10601a8449f446f07b01c2b7f
Previously the RS cpp files are generated by the timestamp rule. Though
we have the generated RS cpp files depend on the timestamp file, we
don't have a build recipe. In such case gmake does some "optimization"
that it skip recompiling the generated cpp files, because it assumes the
generated cpp files are already up to date even if the rs files have
been updated.
Bug: 15313144
Change-Id: Ie69ecd2c788057d3619f9c7d2a125d44c4a534a1
Allow LOCAL_JAR_PACKAGES to work on subpackages. Previously it
only worked on top-level packages due to a bug in how the directories
were recursively deleted.
Add LOCAL_JAR_EXCLUDE_PACKAGES to allow specific subpackages to
be excluded. This rule applies after LOCAL_JAR_PACKAGES has
selected which packages to include. It may also be used independently.
Change-Id: Ibd0e495be1a20c84b59c9da132e92100ef3f8705
_extract-and-include-single-(host|target)-whole-static-lib was written such that
only the first file of a given name would be extracted and included into the new
library. This patch iterates over each identically named archive member,
extracts them individually, and adds them to the new archive.
Bug: 15110069
Change-Id: Ia08c7be6f40bfc8403908a8808898ada479099b1
Previously the odex file is byproduct generated by the package.apk rule.
Though we have the odex file depend on the package.apk it doesn't have
its own build recipe. In case package.apk isn't updated but we still
need to update the odex file (such as changed LOCAL_MULTILIB), the odex
file will never be rebuilt.
This change split out the rules to build the odex file and make sure the
build recipe get executed if the odex file needs rebuild.
Change-Id: I60c2f32b536b3d59045301ee863aae1451734aad
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
"GYP" class targets are used by external/chromium_org for gyp's "none"
type. The processing in these targets needs a separate intermediate
directory for the primary/secondary architecture, so add it to the list
in intermediates-dir-for along with libraries/executables.
Change-Id: Id05899c83b45ed0647dfbfa6b0b2e7f61b04348b
When LOCAL_STRIP_MODULE := keep_symbols is set, then the normal strip rules
will be modified so that only the .debug_* sections are removed. The original
symbol table is left alone.
This allows the compilation of certain libraries so that libbacktrace library
can provide meaningful names to functions.
Bug: 12958251
Change-Id: I82bdc304a463012e29086325ccb51163464cb4a9
The doclava build does not need to depend on the intermedidate
removed.txt. It depends on public_api.txt. Removed.txt is generated
along with public_api.txt by doclava.
BUG: b/11293324
Change-Id: Ia5ea675bbfb15b81ce6ae81cf34c608e83676ca1
