If a dependency has ndk stubs, then the sdk variant of the library
should link against the ndk stub variant and not the impl/apex_stubs variant
Unlike module-libapi, the depdendency does not go through an
@api_surfaces external repo indirection. This indirection was created to
support Multi-tree, and will likely be removed in the future
Test: Added a unit test
Bug: 298085502
Change-Id: Ie081e153fa586b6c22db0b8e42f91149fd8e5d9b
...instead of based on constraint settings.
Bug: 269577299
Test: m nothing and ./build/bazel/ci/bp2build.sh
Change-Id: Ib9caec79c92b8fd304e46be841de5612bd1637e3
host_ldlibs are used during linking. Set these in `linkopts` for now.
Note that this CL does not do the `CheckBadHostLdLibs` validation of
Soong. There are some different ways to do this, and these are being
discussed in b/216626461. It is likely that we will need to create a new
property `host_ldlibs` to do the validation. But for now, re-use
`linkopts`.
Bug: 216626461
Test: bp2build unit tests
Change-Id: Id4c77e4460fb1fb003fa58ea27bab5b50ea8cefe
* changes:
Special case platform variant of bootstrap libs
Select stub/impl per apex variant
For test apexes, base_apex_name is the api domain
Broaden the granularity of config_setting from apex_name to api_domain
Print default val if all vals in axis match default val
For converting the art plugins to pure soong, it would be useful to
have a property that's qualified on both a soong config variable and
the OS. Soong had very little-known support for this by saying your
soong config variable changes the "target.android.cflags" property,
and we didn't supporting bp2building that. Add the bp2build support.
This cl also refactors product variable and soong variable bp2building
so that they're separate from each other, which I think makes the code
easier to understand.
Test: go test
Change-Id: Ic74dc75da8103fa2523da95c3560c9ce3c5e5672
Create a select statement for every api_domain a library could be
included in. The stub/impl
selection heuristics per apex domain are
1. If dep has stubs and the api domain appears in dep's apex_available, use
impl
2. If dep has stubs and the api domain does not appear in dep's
apex_available, use stubs
(Category 3: If dep does not have stubs and the apex does not appear in
dep's apex_available, then a separate apex_available validation in Bazel
will emit an error).
Platform variants have been special-cased for now to use equality of
apex_available for stub/impl selection
Test: go test ./bp2build
Bug: 272378496
Change-Id: Ibd29efd763c8863c7e6d2a9af0da30bbde07175d
These are created by bp2build in /build/bazel/rules/apex. Eventually
these config_settings should likely be colocated with the source apex
definition.
Another alternative was to make Bazel's apex a macro that generates a
config_setting. I did not pursue this further for now since it requires the
apex_available of every allowlisted cc_library to also be allowlisted.
This might not always be true (e.g. com.android.runtime)
Test: go test ./bp2build
Change-Id: Ibbb14b0d9c1491b3c79b7634a18d9d35b03922c1
This fixes two main sources of nondeterminism:
1. Fix a bug in the ConfigurationAxis comparator (which caused
ConfigurationAxis sorting to be nondeterministic)
2. Process C++ dependencies using the sorted ConfigurationAxis order. In
theory, the order in which dependencies are processed shouldn't
matter (as they should end up in different select stanzas). However,
in the case of InApex stubs, this is not the case; we now ensure
that lists are concatenated in a predictable order.
Added bonus: Some cleanup with SortConfigurationAxes which
makes use of go generics (this made it easier to debug this issue).
Will follow-up with regression tests.
Test: Manually verified that build.ninja checksum and BUILD.bazel checksums do not change after running `m nothing` 6 times in AOSP (with comment-only Android.bp changes in between each run)
Change-Id: I81168e45bdbbcd61ea95ff665cf6c4bc180aa4e0
osLinux is implicitly glibc, use //build/bazel/platforms/os:linux_glibc
for the configurability select key for it.
Bug: 259266326
Test: build/bazel/ci/mixed_libc.sh
Test: USE_HOST_MUSL=true build/bazel/ci/mixed_libc.sh
Change-Id: Ifbd121ab3d943f3fdfbd3f6c3e982d1eaaaa9ec1
The axis for OS and in APEX was previously ignoring the excludes from
OS, which would result in excludes for non-Android OSes being
incorrectly ignored.
Test: go test Soong tests
Test: b build //hardware/libhardware:all
Bug: 260131489
Change-Id: Ie77f763bea0f473ac69a0c6b6bc3216e7359ad12
Add barebones riscv64-linux-android support. This should be enough
to add riscv64-specific entries to Android.bp files, but can't
actually compile anything until there are riscv64 toolchains.
Test: arch_test.go
Change-Id: I0dcc7e797d9352dd38243be908a7f19004ff3db1
Fix: 232544453
Test: go tests
Test: b build //frameworks/av/media/module/foundation:libstagefright_foundation
Test: b build //frameworks/av/media/module/foundation:libstagefright_foundation (with in-apex hardcoded to True, non-apex hardcoded to False)
Change-Id: I7b5f356ff6ed31f89a9d9153396bc851d991c487
Bug: 231322789
Test: with this CL on internal master,
1) b build --verbose_failures //vendor/google/modules/AdbdGoogle:com.google.android.adbd --config=android_x86_64
2) adb install bazel-bin/vendor/google/modules/AdbdGoogle/com.google.android.adbd.apex, and adbd is activated successfully on cuttlefish device.
3) m mts && mts-tradefed run mts-adbd, and there is no failure with cuttlefish device
4) packages/modules/adb/test_device.py, and there is no failure with cuttlefish device.
Change-Id: I81b6f5336cacf35c68957ae2dac65f985b6eafb9
Add toolchains to support cross compiling to aarch64-linux-musl and
arm-linux-musleabihf.
Bug: 236052820
Test: build arm and arm64 musl sysroots
Change-Id: I47a9322929baff2492c6e8db989ece01fcbeb133
Also fix some bugs pertaining to configurable attribute handling of bool
attributes and label sttributes, so that they may support values across
multiple different axes at the same time.
Test: unit tests for bp2build
Test: mixed_droid
Change-Id: I411efcfddf02d55dbc0775962068a11348a8bb2c
This just sets up the toolchain and allows Darwin+Arm64 to be specified
as a HostCross target. These variants will not be exported to Make, or
be installed on a Soong-only build. A future CL will add support for
universal binaries using these variants.
This config is a bit stranger than the regular 64/32 multilib, as it's
two primary 64-bit configs. And on a Darwin/X86 machine, the Arm64
versions are HostCross (doesn't work on the current machines), while a
Darwin/Arm64 machine, either version works (if Rosetta is installed).
Bug: 203607969
Change-Id: Iacaed77d267773672da027cd74917e33fb1c1e94
Also refactor target.bionic to be handled not as its own configuration
axis, but instead to be grouped into os selects handling.
This allows us to remove libbase and its dependencies from the bp2build
denylist.
Test: mixed_droid.sh CI
Change-Id: I92f30074d286306207653fe37589835ae3db16c4
- If no system_shared_libs is specified, bp2build writes no attribute
value. In this case, the bazel library macros determine the correct
default behavior.
- If any system_shared_libs is specified for any variant, then bp2build
writes the value verbatim. This includes if an empty list is specified,
as this should override defaulting behavior.
Note this defaulting behavior is incomplete and will be incorrect in
corner cases. For example, if, in an Android.bp, system_shared_libs is
specified for os.linux_bionic but not for os.android, then the bazel
default for os.android will be incorrect. However, there are no current
modules in AOSP which fit this case.
As a related fix, supports static struct for cc_library_static.
Also, removes some elements from the bp2build denylist.
Test: mixed_droid CI
Change-Id: Iee5feeaaf05e8e7209c7a90c913173832ad7bf91
Split the x86 host toolchain into glibc and musl variants
Create new musl toolchains that are based on the existing glibc
toolchains, and add the necessary flags for musl compiles.
This relands Ifc02f9e5afa61ff758be98b0c962f3a4b53d0546 with changes
for I46672e3a096b6ea94ff4c10e1c31e8fd010a163c.
Bug: 190084016
Change-Id: Iaa9f7a50ff601155ecd73acc5701a2c226be66dc
Test: TestArchMutator
Create new musl toolchains that are based on the existing glibc
toolchains, and add the necessary flags for musl compiles.
Bug: 190084016
Test: TestArchMutator
Change-Id: Ifc02f9e5afa61ff758be98b0c962f3a4b53d0546
Soong supports some hand-crafted target.<type> that match multiple os or
arch types to simplify configuring for similar targets. target.bionic is
used to match on both android and linux_bionic OSes for cases where they
should be handled the same way.
Test: build/bazel/ci/bp2build.sh
Change-Id: I47b6aaf3279e4d242c4fd0e12f24117eb98e0665
This allows it to be used for other modules types and other properties
(e.g. static_libs & exclude_static_libs).
Test: go test soong tests
Bug: 188497994
Change-Id: I40ab16e3b540ece0a6684558b32f7e8e25df6f24
This is to simplify the process of resolving label + exclude labels
across the various configuration axes we have and across the various
properties/modules that use this behavior.
Test: ci/bp2build.sh && ci/mixed_droid.sh
Change-Id: I8efae3e75ddb365384f5caaf5bb504a5206618d3
