All introduce a flag LEGACY_USE_JAVA6 to force java6 builds.
This is an unsupported configuration, and provided temporarily
to iron out regressions and compare build output (if required.).
- Increment the version check sequence number.
- Move a more specific check (OpenJDK vs non OpenJDK) after
the more general version check.
- Update the link in the version check error message to the
"initializing" page instead of the "download" page. The latter
talks about repo, mainly.
bug: 8992787
Change-Id: I313e17b1911768d4f3bc318c4162c53dec6eaf0d
Conflicts:
core/main.mk
1) Disable dexpreopt if DALVIK_VM_LIB isn't set up by the product.
2) DEX2OAT_TARGET_INSTRUCTION_SET_FEATURES is moved to config.mk,
for it's only decided by target arch.
3) Move Java module input from embedded.mk to base.mk.
Change-Id: Ife70b0cd8cee2e5c92f356c808affa56f494b49a
Analyzer needed by WITH_STATIC_ANALYZER and WITH_SYNTAX_CHECK is
moved from prebuilts/clang/{linux-x86,darwin-x86}/host/3.3 to
prebuilts/misc/{linux-x86,darwin-x86}/analyzer
See https://android-review.googlesource.com/#/c/83852/
BUG=13243591
Usage:
"WITH_SYNTAX_CHECK=1 make ..." instructs build system to invoke "clang -fsyntax-only"
to utilize clang's better diagnostics before calling LOCAL_CC/LOCAL_CXX for code generation.
The compilation time is slightly longer, and the generated object file should be the same as
w/o WITH_SYNTAX_CHECK
"WITH_STATIC_ANALYZER=1 m/mm/mmm/mma/mmma ..." instructs build system to run static
analyzer via "clang --analyze" on a successful build. If analyzer finds any issue, instruction
to open report is displayed. See http://clang-analyzer.llvm.org/scan-build.html for details.
WITH_STATIC_ANALYZER trumps WITH_SYNTAX_CHECK if both exist. Project use lots of GCC extensions
(eg. nested function) not supported by clang may opt out by adding LOCAL_NO_STATIC_ANALYZER:=true
Change-Id: Ib3dda3ffb0fd3aaf2eadec867a966d1dd2868fb1
1. Following the setup of gcc in build/core/combo/,
we added the [HOST|TARGET]_<arch>.mk clang config files,
and load only the configs needed by the current product.
2. Added support for the 2nd arch.
Change-Id: I2a383418a9688a050b39492f8e489d40eeeb5f2d
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
/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
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
The new option WITH_STATIC_ANALYZER=1 instructs build system to
run static analyzer via "clang --analyze" on a successful build.
If analyzer finds any issue, instruction to open report is displayed.
See http://clang-analyzer.llvm.org/scan-build.html for details.
WITH_STATIC_ANALYZER trumps WITH_SYNTAX_CHECK if both exist.
Project use lots of GCC extensions (eg. nested function) not supported
by clang may opt out by adding LOCAL_NO_STATIC_ANALYZER:=true
Change-Id: I9970560560bd52ce5f0fd7129c3488629627c735
The new option WITH_SYNTAX_CHECK=1 instructs build system to invoke
"clang -fsyntax-only" to utilize clang's better diagnostics before calling
LOCAL_CC/LOCAL_CXX for code generation. The compilation time is slightly
longer, and the generated object file should be the same as w/o WITH_SYNTAX_CHECK
Project use lots of GCC extensions (eg. nested function) not supported
by clang may opt out by adding LOCAL_NO_SYNTAX_CHECK:=true
Change-Id: I5689586788ef049bd967364f71f31f1e359bd121
Support using custom mkbootimg to allow boards to specify custom
boot image formats. Also export this as the environment variable
MKBOOTIMG to the *_from_target_files releasetools scripts.
Change-Id: I2084273b1175de097fb7da5c4f2264ea8014d74f
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Don't bother going through the source tree in more circumstances:
all cleaning goals, helping goals, no-deps goals.
Bug: 10244578
Change-Id: Id53a249085c62838e4193962a85e0ac34f46954f
AndroidProducts.mk allows for a maxdepth of 4 in device and vendor while
vendorsetup.sh and BoardConfig.mk only allow for smaller depth.
Make search depth consistent for these files.
Change-Id: I406770c1423d4f27fe097956a7c705a0da937e35
Signed-off-by: Beare, Bruce J <bruce.j.beare@intel.com>
Signed-off-by: Laurent Fert <laurent.fert@intel.com>
Signed-off-by: Guilhem Imberton <guilhem.imberton@intel.com>
Author: Laurent Fert <laurent.fert@intel.com>
To pick up a NOTICE file in LOCAL_PATH and attach it to
/system/lib/libfoo.so, use the following syntax:
include $(CLEAR_VARS)
LOCAL_MODULE_CLASS := NOTICE_FILES
LOCAL_INSTALLED_MODULE := $(PRODUCT_OUT)/system/lib/libfoo.so
include $(BUILD_NOTICE_FILE)
Bug: 7460213
Change-Id: Ie692be72deab37be04d1b578578c131a0885a090
Default to 4.6, but can overwritten to something else in
prebuilts/gcc/$os/$arch/$arch-linux-android*-$ver
Change-Id: I16f99d642b8ff8e831d392261a0c536041107051
To reduce the start time.
With the change and previous change of doing clean step in only given paths,
start time of mm/mmm is reduced from ~5s to about 1s;
lunch time is reduced from ~40s to 3.5s.
(cherry-pick of 157a5e1695593f935c3223430f4530e21f990378.)
Bug: 7186768,7169854
Change-Id: I0be5e2721efa66a80f112acf8f95e177ebc2f65b
To reduce the start time.
With the change and previous change of doing clean step in only given paths,
start time of mm/mmm is reduced from ~5s to about 1s;
lunch time is reduced from ~40s to 3.5s.
Bug: 7186768,7169854
Change-Id: Ifd72ba1c6362a5e1125a23c505fd47947ab56675
To reduce the start time.
With the change and previous change of doing clean step in only given paths,
start time of mm/mmm is reduced from ~5s to about 1s;
lunch time is reduced from ~40s to 3.5s.
Bug: 7186768,7169854
Change-Id: Ifd72ba1c6362a5e1125a23c505fd47947ab56675
