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
https://source.android.com/docs/core/architecture/aidl/aidl-backends#custom-parcelables
Some aidl files have custom parcelables with references to cpp headers. Hence, we need to pass the include dirs from cc libs to cc_aidl_library so that custom cpp headers are findable by the generated cpp/h files.
Test: go test
Bug: 278704136
Change-Id: I4ede1d23fbc04bdbfb69823d955c6df6b0a7b4ee
Introduce aidl.libs prop on cc libraries to pass in aidl_library. The goal is to eventually disallow aidl.include_dirs (a pattern for passing aidl headers dir for aidl compilation) and enforce aidl headers to be explicitly specified in Android.bp.
Bug: 278704136
Test: go test
Change-Id: Ia78bc11dfa12f47d2d1bb90dc65372ddb17f7e14
We now rely on a `with_features` clause to effectively disable
thumb when `arm_isa_arm` is enabled. Thus, we no longer need to
add `-arm_isa_thumb` in bp2build.
Bug: 261733820
Test: Unit tests
Change-Id: I9da85834855b297a75097ce3a11e101f55bd53f4
For cc_libraries containing .y/.yy srcs, we will generate an additional
cc_yacc_static_library target. This target will produce an .a file that
will be statically linked to the parent target.
Test: go test ./bp2build
Bug: 281546029
Change-Id: I094ba56f0a95869e5bc1e1d38b83c777192b7ddd
* 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
1) Use attribute name "default_package_metadata" instead of
"default_applicable_licenses" in packages to better describe its use.
2) Add a filegroup "default_metadata_file" in packages to search for
METADATA file in each package.
3) Include "default_metadata_file" in each package's
"default_package_metadata" attribute.
Bug: 275472038
Test: CIs
Change-Id: I645c013c39e3190fd96c4a549d39a331aced16bd
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
apex_test do not "override" the source apexes that they test. However,
similar to override_apexes, test apexes have the same path
(/apex/<apex_name>) on device. Instead of creating another property,
reuse the existing base_apex_name property. The use case for this will
be for creating selection statements for stub/impl selection.
Test: go test ./bp2build
Change-Id: I4b7548e0e0fc920e407e1c5e5c00e87efc6e70c9
The use case for this is for creating a select statement for stub/impl
selection. Since Bazel propagates apex_name from the top-level apex,
the source apex and test apex builds a specific library in two different
configurations. We need select statements for both these two
configurations, but this metadata might not always exist in Android.bp
since test apexes are not necessary to be listed in Android.bp files.
To overcome this, the select statements will be created per api domain
instead. This CL uses a naming convention to infer the api domain of
apexes.
Test: go test ./bp2build
Change-Id: Iad2b45f736bc98a24d2ce1cf2f69aad67973092d
Although paths to resource files in a Bazel java_library should be
relative to the package, the directory structure in the resulting jar
will have resources under the full path from the top-level of the
workspace, e.g. if a library in "a/BUILD" has java_resouces as
"res/res.txt" then by default the res.txt file would appear under
"a/res/res.txt".
Fix this by adding a resource_strip_prefix in that case.
Test: Unit tests
Change-Id: If4325126f5c19a2a8fb83ee09bc3a95a18673fe3
To avoid verbosity, we currently dedupe keys in axis if its value
matches the value of //conditions:default. For axes where all values
might match the default value, we would effectively drop the common
value.
To fix this, we are now dropping the select statement and not the common
value.
Test: go test ./bp2build
Change-Id: Ic377b93ee2aba971753f6a5e7a62e15d1fcfa2bc
Instead of exporting it to soong_injection.
Bug: 279095899
Test: m nothing
Change-Id: I7b93af233b7450848a475512b5f5682ece773c09
Merged-In: I7b93af233b7450848a475512b5f5682ece773c09
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
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
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 reverts commit 1db4348734.
Changes from original:
- extracted function to add the current version to stub
versions for bp2build.
- added libc++ to mixed builds denylist
Reason for revert: re-uploading with fix in topic
Change-Id: Ifa0ed456bf8cb4a7f861d6826263adfedb4fdd9c
Previously we were treating it as a shared library only, but
cc_test_library produces both a static and shared library.
Test: bp2build tests
Change-Id: I293d4246d581212b95765fa8f084301514d00dbf
in bp2build. The context here is that `-fvisibility=default` should
only be added for CFI if `-fvisibility=hidden` is not already
specified. This will be achieved using toolchain features. Note
that Soong itself never adds `-fvisibility=hidden`. This is only
ever added in the `cflags` property of a bp file.
Bug: 261733820
Test: Unit tests
Change-Id: Ib821e8c30a9cd03d2929b4bd2e771bec7b33fa66
This reverts commit ca438e6b72.
Reason for revert: ci post-submit failures in aosp-master-bazel of targets mixed-droid-clean and mixed-droid-incremental:
FAILED: ninja: 'out/target/product/generic_arm64/obj/SHARED_LIBRARIES/libc_intermediates/libc.so.toc', needed by 'out/target/product/generic_arm64/obj/EXECUTABLES/updater_intermediates/LINKED/updater', missing and no known rule to make it
12:21:27 ninja failed with: exit status 1
Change-Id: I081b499d23f2568cdf6227c4e3b0278164086b69
In a follow-up CL, we should eventually disallow aidl.include_dirs in cc rules so that the deps are always explicit and compatible with Bazel migration.
Test: go test
Bug: 278059962
Change-Id: Ia786cc8634d03589dc008f10b01e6bb2b9f2c7f0
Bug: 270408757
Test: go test
Test: m NeuralNetworksTest_shared_partial --bazel-mode-staging
&& verify that Ninja commands link libneuralnetworks via stubs
Change-Id: I19bf5a829cea7fd00c0f82511ad2bddbc40fae4f
There was a request for using b with python tests. bp2build python
tests exactly the same way as python binaries so that they can be
used with `b`.
Bug: None
Test: go test
Change-Id: Id68a6a73572745a4885b3e5bb1b8452e36baa982
This CL adds java_version and sdk_version support to bp2build
converters for
- java library
- java binary
- android library
- android binary
- android library import
Although java import doesn't support java_version and sdk_version, the
neverlink java_library wrapper around a java_import must specify a
sdk_version when targetting a device. "none" is used by convention.
Change-Id: I22a69dea2e351858368df69ed6a703b568d613ea
Bug: 215230098
Test: Presubmits
We don't want rules to load the product variables directly, because
then they won't be able to transition on them.
Break constant information that is safe to load outside of the
product vars file, so that we can make the product vars file have
more restricted visibility later.
Bug: 269577299
Test: m nothing
Change-Id: I848bff33e4f5798f51296ea3a2600615cab36985
There was an incrementality bug in the symlink forest generation that
was recently fixed. However, if the appropriate files don't get touched,
the issue will remain. Add a mechanism to clean old symlink forests
so that when we fix incrementality bugs we can ensure they don't remain
in any old out directories.
Bug: 276349152
Test: Presubmits
Change-Id: I36664dfb0ca7227e3e1f89de859ebccb808c5f15
It was possible for the merged content to end up back in the bp2build
generated file because there was a symlink from the symlink forest to
the bp2build generated file.
Remove the symlink if it exists.
Bug: 276349152
Test: m bp2build, add a handcrafted file in the same folder as a Android.bp file, m bp2build again, check that the symlink forest version is not a symlink
Change-Id: Id64aa3addebcf0c6b1728389f21ae246796aaf8d
See the other cl in this topic for more information.
Bug: 269577299
Test: b test --config=android //build/bazel/rules/apex:all
Change-Id: I1f20bc5f85398cd79dc5b7fe9d0bd4d93d442383
These must be added in the soong_injection code as opposed to just
defined loosely in checked-in bzl files because the product_vars
select statement must be updated to support the new platforms.
Bug: 269577299
Test: b test --config=android //build/bazel/...
Change-Id: I7bba9af214896dd3b5938bae70b7c0cea4f75e41
Note this doesn't entirely match Soong's logic but is an improvement to
allow linking against implementation when two cc modules are
apex_available to the same module.
It is not possible to recreate the logic for "directly in" without
significant changes to bp2build as we do not add dependencies nor run
apex mutators. Rather than trying to replicate this, we would be better
off refactoring Soong to no longer support the "directly in apex" logic
and require users to correctly specify apex_available.
Bug: 272378496
Test: go test conversion tests
Change-Id: I17ac426f9b4bdad0c2ab661484e5d994f63568ce
The static deps of the parent library can be necessary to build a
bp2build-generated cc_aidl_library target. We should add these deps as
implementation_deps so that they are accessible.
Bug: 250876486
Test: b build //frameworks/native/libs/gui/...
Change-Id: Ibe7c3598a684907473e2a4e040fb3976455a59e9
BUILD files of rdeps should depend on stubs via @api_surfaces
indirection. e.g. instead of depending on
//system/logging/liblog:liblog_stub_libs_current, it should depend on
@api_surfaces//module-libapi/current:liblog. This ensures that the
generated BUILD files are compatible with Multi-tree.
Update the unit tests for this change.
Test: TH
Change-Id: Ibcc36dcfbee7b1973b341485f015e67987564dcc
Since the source_library attribute of _cc_stub_library_shared was a
label attribute, the source library was added as a dependency of the
stub which doesn't always make sense. E.g. it caused validation actions
for the source library to run even when we weren't building the source
library.
This change converts the label attriubte to a string attribute so that
we don't add the dependency.
Bug: 263390551
Change-Id: I19c62d1e14847dff68ab37156452addaa119eaf9
Bazel boolean attributes can only support true or false states, but the
clang-tidy logic changes for modules which don't set a specific value.
Therefore, the tidy attribute should really be a tri-state of "true",
"false", or "" (unset).
Test: b test //build/bazel/rules/...
Bug: 268681923
Change-Id: I85fbaa612d175f475757db806cea6c018901fe3e
for java_library, java_binary, android_app & android_library
Change-Id: Ia8dec7e7d497eb41b2d8dcd8c44c3090d1d3b4bd
Bug: 271265771
Test: go test ./bp2build
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
This is to match the behavior of BUILD file generation.
Test: m and all existing bp2build conversion tests
Bug: 271122205
Change-Id: I6320a65aaad06114817eaed722cc0a0939c57bc1
there is now support for resoure_strip_prefix in kt_jvm_library targets.
Test: built AnalyzerKt and updated go ./bp2build tests
Change-Id: I4a6fe45276d45519186b6f40a02db990511d6def
Add Alwayslink to bazelPrebuiltLibraryStaticAttributes
Also adjust the corresponding tests to espect these new targets.
Test: m libc
Test: b build --config=android //prebuilts/clang/host/linux-x86:libunwind-exported_alwayslink
Test: bp2build.sh
Bug: 267214124
Change-Id: I4d996aef55321f1827947f00b0eaa52d0a14413e
With this CL, we avoid deleting the bp2build directory and regenerating
all BUILD files. Instead, we regenerate BUILD files which have changes
on the filesystem, and delete old BUILD files which should no longer
exist.
This improves incremental Bazel server performance by about ~5 seconds.
Previously, Bazel would have cache misses for regenerated packages, and
would thus need to analyze them even if no meaningful changes took
place.
For ease of implementation, we avoid removing stale (empty) directories
from the bp2build workspace, but this should have no effect on the
build. (These will be removed on next clean)
Test: New integration tests
Test: Manual benchmarking in conjunction with persistent bazel server
Change-Id: I3e489ff403be34040122876012329060a2506366
Given that we can map them directly to disabling the
corresponding Bazel features: `-{link_,use_lib}crt`
Test: Existing (adapted) Unit Tests
Test: bp2build.sh
Change-Id: Ib502f6fb929ace8e86a1001e3cc21f399317500c
Only public, system, test, module_lib and system_server are
converted in order to generate api_fingerprint.txt in Bazel.
Test: java_sdk_library_conversion_test.go and TH
Bug: 266973526
Change-Id: I67a00806165e5afad3876b6cd5cdbc6b0dd65d8b
This changes bp2build codegen, symlink forest generation, and
soong_build so that they do not rewrite output files if the contents are
unchanged.
Bug: 266983462
Test: m droid
Test: canonical_perf.sh benchmarking
Test: Manually verified that rerunning analysis did not regenerate
out/soong/workspace/prebuilts/sdk/BUILD.bazel unless contents changed
Change-Id: I5ec227df7a32b53c7fa0d741fb1403a51931024b
So that it can be used in the bazel implementation.
Bug: 268006095
Test: m nothing, check that it's in out/soong/soong_injection
Change-Id: I1520dd874076dee7fa083648d0790b060d658e5a
Previously, symlink forest generation involved removing the entire
symlink forest and recreating it from scratch. With this change,
a) symlinks which need not change are untouched,
b) symlinks pointing to the wrong location are fixed, and
c) symlinks which should no longer exist are removed.
On AOSP on my local machine, this reduces the symlink forest generation
step from 2.5s to 1.1s clean, and 0.6s when a single file is added to
a source directory.
Bug: 257528847
Test: m bp2build, touch `fakefile` under the forest, remove a file
from the source tree, rerun m bp2build. Manually verify the new forest
does not retain the link to the deleted source file, and that fakefile
no longer exists in the forest.
Change-Id: I481371ae487e9419af6a3a4370c552578b07d650
Previously, Bazel was invoked during mixed builds with a stripped down
environment. This CL adds an allowlist of environment variables that are
passed to Bazel.
Test: WITH_TIDY=1 DISABLE_ARTIFACT_PATH_REQUIREMENTS=true mss tidy-packages-modules-NeuralNetworks --bazel-mode-dev
Change-Id: I23147bec59f6522953cf623e7bcaa0f1f99a75a3
Test: bp2build tests and locally built MusicKotlin
(cannot allowlist yet due to soong/bazel custom_package differences)
Change-Id: I1cbd0fe2af0e6eeed65cf8d57dc85c1f54646c50
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
This API surface is provided by platform and mainline modules to other
mainline modules. Rename it to module-lib API surface to align it with
the terminology in go/android-api-types
Test: go test ./bp2build
Test: go test ./cc
Change-Id: Ieb9f3214e66366fc2ceb6f47e2d6623acb537827
We were looping over a map, and thus processing files
in a non-deterministic order. Some tests check for errors
produced during the symlink forest creation and they would
flake due to this nondeterminism.
Test: m nothing
Change-Id: Ie1a4cf98e341e4a951f110b7d5611bb69c4ddd2b
Brings down time taken to fail from 18s to 13s (on aosp branch)
Test: temporarily coded random failure
Bug: N/A
Change-Id: Ib694eec977293f4dd7054e779d1b82b8cace93f6
Previously if there was a value set outside of product variables and one
inside a conditions default soong config var, we would ignore the
conditions default. Now, we maintain the conditions default and use
the root value in cases where there is not a value for a product
variable.
Test: go test soong tests
Change-Id: Ic991e3aebe5bb6039353f4e3d25625e7c5190f96
