api providing modules (droidstubs, cc_library etc.) can refer to the api
file via a separate filegroup module. Therefore these modules should be
generated in the api_bp2build workspace as well
Test: m api_bp2build && build/bazel/bin/bazel build
--config=api_bp2build --config=android //build/orchestrator/apis:*
Change-Id: I77371bd94a2794770b01b98aaf84b1bc42810841
Except if BUILD_BROKEN_USES_SOONG_PYTHON2_MODULES is set, and except for
some core py2 modules that can't be removed until python2 is fully gone.
Bug: 203436762
Test: m nothing
Change-Id: I62ccb6f5687eab1e79c372ffc234a90ca5b566ac
Currently, non-apex variants of modules that are in apexes are not
exported to make unless they're apex_available to the platform. This
means that you can't `m` those modules directly.
However, there is a workaround in the apex androidmk implementation that
emits make rules for the removed modules, but just redirects them to
build the apex itself. We want to remove that, but one of the problems
with doing so is that you can no longer `m` many modules afterwards.
To fix that, unhide the apex's dependencies from make. To ensure they're
not installed, call SkipInstall() on them, and update SkipInstall() to
be more strict by setting `LOCAL_UNINSTALLABLE_MODULE := true`.
Bug: 254205429
Test: Presubmits
Change-Id: Ib094feb2c437ad50d8319c58caa997759e7ce32f
Bazel fails to respect the environment variables $LLVM_PREBUILTS_VERSION
and $LLVM_RELEASE_VERSION, which are commonly used by LLVM developers
to build using a custom compiler. Fix it.
Bug: 272408039
Change-Id: I3cf18e7814ff52d526017e4fe34b17ab3d8f1080
- Create the alias under the module-libapi directory. This is the
api_surface that cc_stubs_suite maps to.
- Create the alias only for "current" (atleast for now)
- Create one alias for the stub shared lib, and another for its headers
Test: b build @api_surfaces//... (with aosp/2475091)
Change-Id: Ib004c2c34256f971e74d75317fa5fbbe7273720e
The expected use case for this is to create aliases for stub libraries
in the @api_surfaces repository in build/bazel/api_surfaces.
This restricts the scope to just aliases. If we have a use case for
generating actual Bazel targets in another directory, a workaround could
be to generate the targets in the current directory (via
CreateBazelTargetModule) and aliases to it in the other directory
Test: go test ./bp2build
Change-Id: I6b63d9d018618d447fc7c260a2a94aaa00e57a4d
override_apex's bp2build converter had a bug where it was looking at
the product variables for the override_apex module itself instead of
for the base module it is overriding.
Fixes: 271424349
Test: go test
Change-Id: If1e2653d3751fa908faf0ab97dfa2e943ebe98ec
Armv9 with mandatory PAC and BTI extensions.
Stack protector is disabled as it is irrelevant with PAC.
Bug: 263283855
Test: NFC
Change-Id: I2f298f21dade12824597e0a6920772a2bfc63afb
Unlike most module types, config variable handling is always namespaced
to the Android.bp file, which limits reuse of the variable definitions.
Additionally multiple of these module types can define a string variable
in the same config namespace, but specify different valid values for the
string.
Previously, we cached the first instance we see of variable + namespace;
however, this caused non-determinism in which defintion would be used
and not migrating all values. Instead, we now only cache within a single
Android.bp file where the variable definitions are re-used.
Test: go tests
Bug: 271481817
Change-Id: Ic327657c508e47a705bacd24712a1916e105c7cd
Add definitions for the Cortex-A32 CPU. This is an aarch32 only ARMv8-A
core. See more here https://developer.arm.com/Processors/Cortex-A32 .
Test: added new minidroid target using this CPU variant and built
Change-Id: Id2351a43b9c6cb9785ef469b8c13fadd8b6324b8
Signed-off-by: Mark Slevinsky <markslevinsky@google.com>
Signed-off-by: Jesus Sanchez-Palencia <jesussanp@google.com>
can allowlist instead. bp2build now handles kotlin srcs
Change-Id: I0f96eb50cbb5bd2c6dc69f253b1a35cfd4edecf2
Test: built codegen_cli with bazel
Bug: b/245731902
