Calling reflect.ValueOf for every variable for every module was
using ~3 seconds of CPU time on my AOSP builds.
Test: m checkbuild
Change-Id: Idf459ad8ddf5e07f6c0df0e58e2442aaa6ab3342
The vendor snapshot header globs were repeated 9 times, once for each
possible header suffix. Globbing is not a fast operation, so this
took 9.68s of CPU time in my AOSP builds. Replace it instead with a
single glob, followed by filtering down to the desired header
extensions.
Test: m checkbuild
Change-Id: I9c8f8cdad8cbffc0a42217659a48dd9d676e4e4c
Bug: 176171716
Test: build_mainline_modules.sh and ensure that the ART boot image is
built: `find out -type f -name '*.art'` is nonempty for every arch.
Change-Id: Ibc45581eef2b205c750a30709780cf659ba7cfa1
Currently, when a module is included in an APEX, the dependencies of the
modules are listed in LOCAL_REQUIRED_MODULES of the APEX. There are two
purposes for this:
1) for native dependencies, they are installed to
$(TARGET_OUT)/apex/<apexname> directories which isn't packaged as an
*.img. However, as a side effect of the installation, their symbol files
are placed under $(TARGET_OUT)/symbols directory to aid debugging.
2) to implement the symlink optimization. When the APEX is not
updatable, the dependencies are not included inside the APEX, but
installed directly to /system partition because the same files might be
used outside of the APEX. The files in the APEX are replaced with
symlinks to the system copy.
So far, the module name like "libfoo" was directly used in
LOCAL_REQUIRED_MODULES. This becomes problematic when only a single arch
variant of the module is used by the APEX. The build system will install
both arch variants to the system partition.
This change fixes the problem by appending ":32" or ":64" suffix
when composing LOCAL_REQUIRED_MODULES.
Bug: N/A
Test: m
Test: Cherry-pick I285c5d1bb9b27265c8589f2588d95eafa324d412 and its
dependencies from internal master. `m nothing` doesn't show the artifact
path requirement error.
Change-Id: I78feae1d5b18f93b0f984d3b1558812fd1689a96
* WITH_TIDY=1 should not include clang-analyzer-* checks
because they are too slow.
* Nightly builds will use both WITH_TIDY=1 and
CLANG_ANALYZER_CHECKS=1.
Bug: 173736193
Test: make with WITH_TIDY=1 and CLANG_ANALYZER_CHECKS=1
Change-Id: I3885fd0e20475ceee5e3798bffc11a61994ac113
Use_avb and other avb_* properties allows us to sign an
android_filesystem module with avbtool.
Bug: 172415113
Test: m
Change-Id: Ifa1ed8ded1b10170aaca9b34e6a14f0179dbab5d
Native bridge modules never need to build against NDK stubs, so
don't create SDK variants. Also clear the sdk_version property
for modules that don't have SDK variants so that later code doesn't
use it to trigger SDK behaviors.
Test: m checkbuild
Change-Id: I1920fa82e9fab06235f01a62624382efa16cc6e3
Previously, the build failed if the directory already existed,
so mixed builds had to be null builds.
Test: lunch aosp_flame && USE_BAZEL=1 USE_BAZEL_ANAYSIS=1 m libc &&
USE_BAZEL=1 USE_ANALYSIS=1 m libc
Change-Id: I167cb82b3e47e9388a1ebca7daffe45f91474125
Without LOCAL_SOONG_DEX_JAR, ninja fails with a missing
dependency error.
Test: m nothing
Test: new TestImportSoongDexJar
Bug: 173705556
Change-Id: I54a4c6ea93877667a3fb97f8b2621c42e431f577
With the addition of the compile_dex property to the
java_import module it becomes possible to include a
java_import module in an apex. This change allows the
dependency and adds a test.
Bug: 177228901
Test: m nothing
Test: new TestApexWithJavaImport
Change-Id: I9336dade1857109e2fd21f7d57e1dc4abc4a402c
By enabling these hiddenapi CSV files to be prebuilt, it
becomes possible to create a split build that supports
the hiddenapi encode dex step, but doesn't contain all
of the java sources needed to generate the CSV files.
Bug: 175048716
Test: m nothing
Test: new TestHiddenAPISingletonWithPrebuiltCsvFile
Test: local build without prebuilt hiddenapi
Test: local build with prebuilt hiddenapi
Change-Id: I805ea3ec05860d2df211a3985ec025bf36f0d775
Implement bp2build codegen as a discrete step that runs after an
alternatively registered pipeline of mutators, instead of a
presingleton.
bp2build codegen requires a Context that supports VisitAllModules and
PathContext, so this CL also makes a BpToBuildWrapperContext that
conforms to PathContext by adding two method implementations.
Test: GENERATE_BAZEL_FILES=true m nothing && bazel query //... --config=bp2build | wc -l # 31433
Test: m queryview && bazel query //... --config=queryview # 63638
Change-Id: I0dd359746584b228046d2d0ff00895f28f9bdfc3
