rbc_dashboard.py is an alternative implementation of
rbc_regression_test.sh. These tests both run soong 2 times with
starlark product config enabled/disabled and diff the resulting ninja
files. However, the shell script test runs the soong invications in
series and the python one runs them in parallel, meaning the python
one is faster. On my computer the shell one takes ~7 minutes and the
python one takes ~4 minutes.
Bug: 291548757
Test: Presubmits
Change-Id: I20fd6ca09f47dd0547f2681fbd78ba70991493b0
product SBOM of cuttlefish devices, ignore these diffs for now in the
SBOM integration test to fix the CI breakage.
Bug: 291073898
Test: build/soong/tests/sbom_test.sh
Change-Id: Idf5569f67642784ee422847301c59dddc8ff0907
In preparation for adding the ability to check all genrules in the tree.
Bug: 290816499
Test: ./build/soong/tests/genrule_sandbox_test.py extensions_db.pb
Change-Id: I6454be7e88a876a2ab1105c04f5ecda03ecd7771
1. UnboundLocalError: cannot access local variable 'output' where
it is not associated with a value
2. `build/soong/tests/genrule_sandbox_test.py WmediumdServerProto_cc`
would try to build the entire world due to 3)
3. WmediumdServerProto_cc 's module action desc had '}generate{'
without a space which would cause 2)
Bug: b/287470077
Test: build/soong/tests/genrule_sandbox_test.py WmediumdServerProto_cc
Change-Id: Ie9d5db44195a6f700cc876ec889bd01c11e66cff
The parsed BUILD files will be scanned for obvious definitions of BUILD
targets which have Android.bp counterparts. In such cases, bp2build will
automatically omit conversion of these defined modules (to prevent
collisions). With this change, we no longer need one-off denylisting of
modules which have BUILD file definitions.
This has a 0.03s to 0.2s slowdown for bp2build with current state. This
impact is identical on a heavier test branch, as well. I also ran an
experiment that applied BUILD scanning to all source BUILD files
(regardless of allowlisting), and this had a 2 second slowdown.
We may want to look into parallelizing or improving the performance of
this evaluation, but it's probably not worth the effort at this time,
since the current performance hit is small.
Test: New integration test
Test: Removed libprotobuf-python from denylist and tested building the
package
Test: Treehugger
Change-Id: Ibde3bab12cd4a8fed642ad46e5344a56953bec91
Unfortunately, genrules are not always available with `m`, instead we
need to know their output paths in order to build them and diff them.
Rewriting in Python lets us store module:output path maps more easily.
Test: ./genrule_sandbox_test.py gen_fstab.gs201 \
libbt_topshim_bridge_header \
android-support-multidex-instrumentation-version
Change-Id: If74130e5a4381cc0e1fab396ebb90dfd5a595a1c
This is a followup to aosp/2606989.
This flag is not necessary now that we're using one platform name
for all of mixed builds.
Also rename current_product to mixed_builds_product so that it's clear
that that this platform should only be used for mixed builds.
In addition, make the bazelrc files point to the named products again
instead of the mixed build product so that b builds will still have
qualified outputs, but mixed builds won't.
Test: Presubmit and kernel build tools abtd run
Change-Id: I7f764cf42cd1323f4b495d1320931f59a076ac63
This is a followup to aosp/2606989.
This flag is not necessary now that we're using one platform name
for all of mixed builds.
Also rename current_product to mixed_builds_product so that it's clear
that that this platform should only be used for mixed builds.
In addition, make the bazelrc files point to the named products again
instead of the mixed build product so that b builds will still have
qualified outputs, but mixed builds won't.
Test: Presubmit
Change-Id: I5acbd18869589f67efb0ad3ebfda2c4d5a6a3850
The CFI transition being applied creates a situation where Bazel
clears its convenience symlinks. This change points the script
directly to the location of the deapexer artifact instead of the
symlink.
Bug: 261733820
Test: Ran the tests
Change-Id: I23951f0fe75ce1fbc3c0dd969244a797ac1ff983
`rm -rf out` used to fail because bazel would not set write permission on some files. Now it's been fixed and thus there is little reason to prefer `m clean` (also users are accustomed to `rm -rf out`)
Bug: NA
Test: verified `m clean` works;interestingly soong_metrics file is created at the end
Change-Id: I000d16508613045811fc7792e5798f7c150dcc05
This change adds missing dependency of Soong modules as symlink
directory in create_mock_soong so that a correct ninja graph can be
created when invoking androidmk_test.sh.
Test: build/soong/test/run_integration_tests.sh
Bug: 283905797
Change-Id: I7dff0094fdc23b7c438c917dbc00a5143a4dc5ae
This fixes an incrementality bug that resulted in superfluous
build.ninja regeneration after a new glob definition is added.
Fixes: 279674820
Test: Treehugger
Test; New integration test in this CL
Change-Id: Ifefe66a0eb1c125e9ad5373d60437a1cb1e6fdec
There are a number of instances where we are exporting information
from soong to bazel via soong_injection. This could be more bazel-centric
if the information was instead held in bzl files, and both bazel and
soong read it from there.
Add a starlark package that will run
//build/bazel/constants_exported_to_soong.bzl at initialization time,
and then results can be retreived with GetStarlarkValue.
Since changes to the starlark files mean that soong has to rerun,
add them as ninja deps.
Unfortunately, the starlark code has to be run at runtime rather than
pregenerating their results, because tests run from intellij wouldn't
go through any pregeneration steps. This means that starlark is run
multiple times during the build, once per test package and once per
primary builder invocation. (currently 3, could be reduced to 2 if we
made the symlink forest generation into its own standalone tool) The
starlark code we have so far in this cl is very fast, roughly half a
millisecond, so it's not a big deal for now, but something to keep an
eye on as we add more starlark constants.
Bug: 279095899
Test: go test
Change-Id: I1e7ca1df1d8d67333cbfc46e8396e229820e4476
Currently, there is little verification around allowlisted modules
actually being mixed-built. This flag would allow us to verify
that a module allowlisted is mixed-built for at least one variant.
Bug: 278910100
Test: m nothing --bazel-mode-staging --ensure-allowlist-integrity
Test: m nothing --bazel-mode-staging --ensure-allowlist-integrity
--bazel-force-enabled-modules=com.google.android.neuralnetworks (This
fails, as expected)
Test: build/soong/test/mixed_mode_test.sh
Change-Id: Icd5976f4f44f1a8caca1e5247d986642f7995f97
Currently, the expected output shows as the main text for
unrelated presubmit failures.
Bug: 278748024
Test: build/soong/tests/mixed_mode_test.sh
Change-Id: I553a82597c7c7791a822e330eb9b2663f35567a1
