Previously, it stored an android.Context (no pointer) which while it
worked (because the current contents are themselves pointers) it is
inconsistent with how the rest of the code references it and could
cause weird behavior if additional fields were added to the Context.
Test: m nothing
m bp2build
Change-Id: I9c70f925dde85e5b15431cc232b0c2eb6371ec6d
The internals of CodegenMetrics was updated in aosp/2276671. Use the
new API to initialize an empty object to prevent a null pointer
exception in api_bp2uild.
Test: m api_bp2build
Change-Id: Iad9c38b9881da896171f1c6d4e49d4875acfaab8
It was assigning --bazel-mode-staging to cmdlineArgs.BazelMode, which
looks wrong.
Test: presubmits
Change-Id: I24b087977fc6861eef3a1c30e58d9bf42a344c52
Bug: b/256212479
Test: Prior to thi CL bp2build.symlink_forest event was missing in bp2build_metrics.pb after a clean mixed build
Change-Id: I53bfc4114a383c0d1f9c4c7945e7d4c69bc50b0c
This helps with incrementality a lot: the symlink forest must depend on
almost every directory in the source tree so that if a new file is added
or removed from *anywhere*, it is regenerated.
Previously, we couldn't do this without invoking bp2build, which is
quite wasteful because bp2build takes way more time than the symlink
forest creation, even though we do the latter in a very suboptimal way
at the moment.
This means that if a source file is added or removed (which does not
affect globs), we don't pay the cost of bp2build anymore.
Also refactored symlink_forest.go on the side. Too much state was being
passed around in arguments.
This change reimplements aosp/2263423 ; the semantics of not touching an
output file is the exact same as order-only inputs and the latter is a
bit fewer lines of code.
Test: Presubmits.
Change-Id: I565c580df8a01bacf175d56747c3f50743d4a4d4
- the generating rule has `restat=true`, so its output need not have a newer timestamp to prevent it from rerunning on subsequent ninja invocations
- its dependents (so far only bootstrap.ninja's "build build.ninja") already have proper dependencies in the depfile, namely
1. Android.bp.list,
2. entries in Android.bp.list,
3. bazel.list and
4. entries in bazel.list
This change prevents symlink related changes from spuriously retriggering build.ninja
Change-Id: I93f1fea7054dfbfc7c13ece34d2d1f07a81bbe07
Test: manually verifying bazel analysis is triggered only under the right set of CUJs using build/bazel/ci/incremental_build.py
Bug: b/239044236
This is okay because Blueprint already adds the module files to the
.d file of its output, so until now, they were duplicated.
Test: presubmits
Change-Id: I1bb75c5124aadd1703f3d150948dd7540ba772be
Bug: b/255309129
Test: `lunch aosp_x86-userdebug` and `export NINJA_ARGS="-d explain"`
Then do the following:
1) rm -rf out && m bp2build
2) touch bionic/libc && m bp2build
3) ALLOW_MISSING_DEPENDENCIES=true m bp2build
After each step above observe the following two
a)`stat out/soong/soong.environment.used.bp2build | grep Modify`
b)`stat out/soong/bp2build_workspace_marker | grep Modify`
Verified:
step 2 changes only (b) - prior to this CL, it'd change (a) as well
step 3 still changes both (as expected)
Change-Id: I98a94878a14e19043f448b0904fc67d5d1dc9733
This is to use bazel to build targets that are being prepared for an
incipient release to the prod mode allowlist.
Bug: 254265047
Test: m nothing
Test: m nothing --bazel-mode-dev
Test: m nothing --bazel-mode-staging
Change-Id: Ic78a59cf51dba83ef1ac26483586560ea9b24aaf
Bug: b/239044089
Test: run build/bazel/ci/incremental_build --bazel-mode com.android.adbd and see the additional metrics in summary.csv
Change-Id: I2c3b9cead2ee43c700a9ad52e669a64aab1499ce
The generated Bazel workspace will only contain api specific targets.
This is feasible since these targets do not have any cross dependencies
with the targets in the bp2build workspace
The advantages of a new mode are
1. Does not pollute bp2build workspace with api targets
2. Does not block api targets with the current allowlist conversion
mechansims in bp2build
(In the future we might want to combine these two workspaces)
A Soong module type will generate a Bazel target if it implements
ApiProvider interface
Test: m apigen
Test: m nothing
Change-Id: I69c57ca6539f932e0ad554ce84a87fb7936fdba0
Previous behavior:
- Packge not listed in bp2buildKeepExistingBuildFile:
- Use bp2build generated build file
- Package listed in bp2buildKeepExistingBuildFile:
- Use handcrafted build file even if there were allowlisted bp2build
modules in the same package.
- Package listed in bp2buildKeepExistingBuildFile and a soong module has
a bp2build: { label } attribute:
- Merge the handcrafted and bp2build generated build files
New behavior:
- Packge not listed in bp2buildKeepExistingBuildFile:
- Use bp2build generated build file
- Package listed in bp2buildKeepExistingBuildFile:
- Merge with bp2build generated build file.
Bug: 234167862
Test: ./build/bazel/ci/bp2build.sh
Change-Id: Ifbaf4f8f0f5158b5b2bd6d534eb2311e2e5f399b
This allows "bazel mixed builds prod mode", in additional to reworking
the mechanism in which mixed builds dev mode is enabled.
As a followup, CI scripts will be migrated to use the new flags, as
USE_BAZEL_ANALYSIS=1 is deprecated.
Test: Manually ran --bazel-mode with an allowlist verifying that the
module alone was enabled
Test: Manually verified --bazel-mode and --bazel-mode-dev cause a build
failure
Change-Id: If0d34360e60452f428b05828f4ec7596b7cb619a
This refactoring prepares for introduction of bazel prod mode, an
alternative mechanism for mixed builds allowlist handling.
* Decide bazel-mode as close to soong_build main as possible
* BazelContext itself decides whether a module is allowlisted
* Separate bp2build and mixed build allowlist
Test: m nothing, manually verified all modules are mixed build disabled
(via metrics)
Test: USE_BAZEL_ANALYSIS=1 m nothing, manually verified that mixed build
disabled/enabled modules are identical before and after change.
Change-Id: I0f55d8b85000cb4a871a099edc6d7d868d7df509
- Top-level trace for all soong_build runs
- Includes adding Peek() to OncePer because not all soong_build
invocations have GenerateBuildActions run.
- A trace per mutator invocation
Test: m && build/bazel/scripts/print_analysis_metrics.py
Change-Id: Ief5c04630484fb38ec7e3757de45c7dc294d3b3c
On the build servers, LOG_DIR is a subset of DIST_DIR, which encodes the
build number. This means that LOG_DIR is guaranteed to be different for
every build, and we'll never re-use previous soong runs on CI builds.
The current use case (writing out soong metrics) shouldn't care if the
value changes, so pipe the environment variable through, bypassing the
env dep checks. It's not clear if this is the only issue triggering
soong_build re-runs on the build servers, but it's a start.
Test: Change DIST_DIR, soong_build does not re-run.
Change-Id: I59bf117f3fbc0e7f10f0506d3d1ac7564c6a00dc
This was accidentally removed in aosp/2094705. Among other possible
issues, this caused the "used environment variable" file to be omitted
from the depfile of soong_build during mixed builds, which would result
in soong_build not being subsequently retriggered during env var
changes.
Sendng this out as a quickfix, regression test to follow.
Bug: 233774464
Test: Manual `m nothing && USE_BAZEL_ANALYSIS=1 m nothing && m nothing`,
verifying that a rebuild was retriggered in each invocation.
Change-Id: I1d9dbd1bc4696df760ebb9be262bc165c161bb21
This large refactoring has both immense performance implications and
improves mixed builds complexity / usability. Summary:
1. Queueing calls to Bazel is done in a new mutator instead of a full
soong_build pass. Normal soong_build flow is interrupted (via a
functional hook in blueprint) to invoke bazel and parse its response.
2. Implementing mixed build support for additional modules is as simple
as implementing MixedBuildsBuildable. In this interface, define the
request that must be queued to Bazel, and then subsequently define
how to handle the returned bazel cquery metadata.
3. Mixed builds consists of only a single pass. This greatly
improves mixed build performance.
Result:
A 33% runtime improvement on soong analysis phase with mixed builds.
Caveats:
C++ BazelHandler handling still remains a bit of a mess; I did what
I could within this CL's scope, but this may require additional cleanup.
Test: Treehugger
Test: Verified that aosp_arm ninja file is bit-for-bit identical with or
without this change.
Change-Id: I412d9c94d429105f4ebfafc84100d546069e6621
Metrics are added to a materialized protobuf soong_build_metrics.pb
Recorded events have scoped names and recorded runtimes.
For example, mixedbuilds includes the following events:
mixedbuilds.prepare
mixedbuilds.analyze.write_files
mixedbuild (this is a total of all mixedbuild events)
Test: Manually verified materialized protos for mixedbuild, bp2build,
and legacy build.
Change-Id: I2e72d4502c0373bee0279bb1320b2e4dd586129c
Tie verbosity of bp2build to env var BP2BUILD_VERBOSE
Test: m bp2build
Test: BP2BUILD_VERBOSE=true m bp2build
Change-Id: Ib8f10ad73ed06c935126a77d18c1d9febc25348f
This is necessary because GenerateAndroidBuildActions() is effectively a
mutator and therefore can change the data stored in each module.
Sometimes one wants to dump that data in the JSON module graph, and in
order to do so, actions need to be generated.
I briefly entertained removing StopBeforePrepareBuildActions(), but it
incurs a 10-second penalty on "m soong_docs" and "m bp2build" so I
decided to keep it.
Test: Presubmits.
Change-Id: I438aaf981e989dc39a09e8a2ba73f7a08ee55386
Soong writes out text protos for the sbox manifests, and if those change
every time soong changes, we trigger rebuilds of significant portions of
the tree. This is very annoying when attempting to iterate on Soong, so
disable this functionality at the soong_build level.
Bug: 200727888
Change-Id: Icf21e1775a4c4200e983c1b8ac66ddd780d7c90c
They were a bit repetitive.
In addition, make the environment checks more correct; they could
probably use an integration test or two to make sure that when the
environment changes, exactly those outputs are rebuilt that need to be,
but for now, this is an improvement already.
Test: Presubmits.
Change-Id: Idd79b81ca6975d57d00e5bf4699d266152505ff8
This makes soong_ui the only place where soong_build is invoked, thus
greatly simplifying the conceptual model of the build.
It comes with the slight limitation that now soong_docs (and queryview
and the JSON module graph) are not Make targets anymore, but I suppose
that's an acceptable loss.
The only place where someone depended on soong_docs from a Makefile is
removed in a separate change.
Test: Presubmits.
Change-Id: I3f9ac327725c15d84de725d05e3cdde1da3dcbe2
Its value is a function of the call site, so it doesn't make a lot of
sense to plumb it through the configuration.
Test: Presubmits.
Change-Id: If928b34de075969fd42932212ce9187808cbdf86
It used to be invoked from out/soong/build.ninja, which required two
soong_build invocations one after the other (ne to generate
out/soong/build.ninja, one to generate the queryview workspace). This
was slower and required some shell-quoted-in-ninja-quoted-in-Go .
Test: Presubmits.
Change-Id: Idda79c067606663b66e9f94626fa24f3b5af4114
They both used to return out/soong. Unfortunately, the tests seem to
assume the old behavior, so I had to keep tests inconsistent and I was
scared of dexpreopt, too.
Test: Presubmits.
Change-Id: Ib00c7956fd2cdb28cc11d481c17e5a3ff5ad563a
It was confusing because bootstrapping uses two configurations: the
"global" config and the special-cased bootstrap one.
This change merges them.
Test: Presubmits.
Change-Id: I82b482cbe28a343ab6991374b2a28667e1a06b48
These are: TopFile and GeneratingPrimaryBuilder.
Also re-shuffle the list of flags to make a bit more sense and finish
the rename of BuildDir and NinjaBuildDir to SoongOutDir and OutDir,
respectively.
Test: Presubmits.
Change-Id: I103ff5f09f1c0d16f695a7da5dea13b55028e33e
Before, we piggybacked on the implementation of regular soong_build and
wrote a fake build.ninja file to satisfy Ninja.
Now, instead, the JSON module graph is a a separate action in the Ninja
output file. This has the pleasant side effect that one can flip back
and forth between generating the JSON file and regular Soong without
loss of incrementality.
Side cleanup: write .d files in a slightly cleaner way.
Test: Presubmits.
Change-Id: Ia853383567b9dd31c53f3bdf56cfc8d517b498ec
These are just out/ and out/soong/ and the old names were quite
confusing.
Test: Presubmits.
Merged-In: I999ca62162062f27e449f83ffb00fa580d4065b8
Merged-In: I2fcd80a9e376a6842a06aa104a9f6f5c5e16f8c7
Change-Id: Ib481d2aac40df8da1b74174dc8ec576c1cb48be0
In particular, the writing of build-globs.ninja and the collection of
glob list files for build.ninja.d is now done outside of the Blueprint
invocation.
This is useful because RunBlueprint() is sometimes called multiple times
in a single soong_build invocation and because now glob processing is
not hidden by the machinery of Blueprint.
Test: Presubmits.
Change-Id: I6eb19b357901e452e6d1e7ce055f8a3bab4a74f4
They used to be defined in Blueprint but since it doesn't have a
separate existence anymore, we can consolidate all command line
arguments here.
Note that Blueprint is called directly from soong_ui, but that happens
by a simple Go function call and not by invoking a separate binary, so
command line arguments are not needed there.
Test: Presubmits.
Change-Id: Ifa2c101ddbe424b76fc5a508d3d41c329e7353ca
The following files are forked:
- build-globs.ninja
- The glob list files
- .d files for the glob list files
- The output file (build.ninja or the bp2build marker file)
This makes bp2build and soong_build not overwrite each other's files
they need for proper incrementality.
Test: Presubmits.
Change-Id: I69d192cbd36ecd9677f46f3fa095dfce6f872227
This fixes null bp2build builds.
When running bp2build, out/soong/.bootstrap/build-globs.ninja wasn't
generated, therefore none of the globs in out/soong/.primary/globs have
actions to generate them. This makes bp2build always re-run on a null
build, because it depends on those non-existent globs in its depfile.
Fix the above by generating a build-globs.ninja file with the globs that
bp2build encounters during conversion, and add tests to verify that null
builds and bp2build -> soong workflows correctly regenerates the
build-globs.ninja file.
Test: soong integration tests for null soong->soong, bp2build->bp2build and bp2build->soong builds.
Fixes: 193650250
Change-Id: Icfbad351dfa85541d1ea451f73e65cac87097926
