This reveals unintended mistake (setting a wrong target partition) at
build-time instead of runtime, which is much harder to debug.
Bug: 280368661
Test: m nothing (soong test)
Change-Id: Ic5e5e97ba918e24f7a59aceb405c2b105e28cccc
We now ensure that the module is disabled and _not_ enabled before
failing the build.
Bug: 280439299
Test: m nothing --ensure-allowlist-integrity --bazel-mode-staging (on
master and aosp)
Change-Id: I59c969a27b064f07913a511cb29bc06d23daa371
Prevoiusly, we were partially correcting for override modules in
bp2build/mixed builds in some but not all places. Now we always check
for override modules and ensure that Bazel_module properties are
propagated properly for override modules.
Bug: 279609939
Test: go test soong tests
Change-Id: I5445aa71f4c8013315415a2ca9ab9c6b3be6bce0
Instead of exporting it to soong_injection.
Bug: 279095899
Test: m nothing
Change-Id: I7b93af233b7450848a475512b5f5682ece773c09
Merged-In: I7b93af233b7450848a475512b5f5682ece773c09
The use case for this is creating config_setting(s) specific to an apex
variant and selecting stub/impl in that config_setting. We likely need
only a handful of such config_setting(s), but determining that list
requires iterating the build graph.
Test: go test ./bp2build
Change-Id: I9aa552e3d0bcf67513023c3a7d4bbf8fae464ee4
The default ELF segment alignment will be 4096. This alignment
can be overriden by setting the desired alignment in
PRODUCT_MAX_PAGE_SIZE_SUPPORTED flag. The alignment has to be
a multiple of the configured kernel page size.
Test: Built changes for Pixel 4a, 6 and checked alignment.
Bug: 276963698
Bug: 276801883
Change-Id: Icb380041a5b27da1fa0d86b302e1e7cde9a236d7
Soong does not enforce apex_available on the contents of test apex. To
prevent special-casing test apexes in the apex validation aspect in
Bazel, drop the test apexes from the tags altogether.
( The core problem I am trying to solve is making sure that stub
libraries in Bazel have a single apex available. apex validation happens
to be a nice side benefit)
Bug: 277651159
Test: go test ./bp2build
Change-Id: Ibb3cfedb5c0f2cda0464bf3758c70b67cb5885d1
Previously, CopyOf on an empty list was returning nil. With the updates
to SortedUniqueStrings and FirstUniqueStrings, we need to differentiate
between empty lists and nil.
Test: m nothing
Change-Id: I91063ebbe5013cbda5d8f70efde4683c66581599
The core problem I am trying to solve is making sure that stub
libraries in Bazel have a single apex available. In Soong, this will be
enforced using some graph walk which is not easy to port to Bazel.
However, we might need to revisit this when we build the enforcement
mechanism in Bazel. We likely need a `test_for` on the top level
apex_test Bazel rule so that the test apex is _allowed_ to link against impl
of the library it is trying to test.
(This CL retricts this to cc_library, I can expand this to other modules
if this is the right approach.)
Bug: 277651159
Change-Id: Iaeec22c5626df79a33785c766ed29102b1da403e
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
This was added to use 'make' target in soong. It was a hacky way and
caused many problems:
- can't track dependency
- doesn't work with sanitizer
- VSDK snapshot doesn't support
- ..
Now references are all gone. Let's remove it.
Bug: n/a
Test: m
Change-Id: I0336a490780f37a4e77d343c61315686e23db643
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
SortedUniqueStrings and FirstUniqueStrings dedupes repeating elements
and returns the deduped list. Currently, it also modifies the input list
in-place, which causes non-determinisitc failures like b/275313114
Operate on a copy of the input so that the input remains untouched.
SortedUniqueStrings is O(NlogN) and FirstUniqueStrings is ~O(N), so
creating a copy (O(N)) should not result in major performance regressions.
Numbers for this single unit test:
```
go test . -run TestStubsForLibraryInMultipleApexes -v -count 1000
Before: 174s
After: 172s
```
Test: go test ./android
Test: go test . -run TestStubsForLibraryInMultipleApexes -v -count 1000
Change-Id: Id859723b2c2ebdc0023876c4b6fabe75d870bad7
- Creation of a bazel command is independent of test/real implementation
- Use a custom struct instead of cmd.Exec
- Move mock bazel runner to the test
Bug: 270989498
Test: m nothing
Test: USE_PERSISTENT_BAZEL=0 m nothing
Test: Treehugger
Change-Id: Ieec35dad5e21aac644d5b8dc79a92397d42db861
Modifying the list in-place causes some non-determinism.
Test: go test ./cc -run TestStubsForLibraryInMultipleApexes -count 1000
Bug: 275313114
Change-Id: Ia2519e146d97667ad5900cf68ab9935fcbaf08a4
We can just rely on the prod/staging allowlists which name the modules directly.
Test: presubmits
Test: m nothing; showcommands adbd_test | grep bazel-out
Fixes: 279004435
Change-Id: I666855d6bbe63c628256c3eebd7ae581c0cbdedb
Environment variables HWASAN_INCLUDE_PATHS and
PRODUCT_HWASAN_INCLUDE_PATHS can be used to enable HWASan for multiple
modules, by just adding the module directory to the env variable.
Bug: b/271948407
Test: Set specific module directory to above env variable and check the
assembly codes of output elf files after building, finding hwasan
related symbols inside.
Change-Id: Ic49b515830c4469ca5fa94f547b26c0fb602fc54
If any of apexes in apex_available is an apex_test, then that name will
be propagated down from that apex to each apex variant. This metadata
will be used to enforce that stub libraries cannot have more than one
apex_available.
This logic is necessary so that bp2build can select the correct
stub/impl.
(To avoid replicating this complexity in Bazel, we should consider
dropping the test apexes in Bazel BUILD files, next CL)
Bug: 277651159
Test: go build ./apex
Change-Id: I63617c1dc2a2d5c9cd7758c416fec7b4db1f10a7
If apex_available is missing from Android.bp files, ApexAvailable
returns [//apex_available:platform], which is the default. To avoid
BUILD file verbosity, remove the build system default value from the
generated BUILD files.
Bug: 277651159
Test: go test ./bp2build
Change-Id: I4129c2a93ac28578f46ebeed49baa23ce727aa1f
