In other words, if, in bp2build, module "foo" would generate "foo",
and "foo_two", and "foo_two" already exists in a build file,
bp2build should label "foo" as being unconvertible.
Fixes: 301321658
Fixes: 301312582
Bug: 285631638
Test: Unit tests
Test: Verified that `m bp2build` results in bit-for-bit identical
contents for out/soong/bp2build before and after this change.
Change-Id: Icbbdd69fce83579ec9b172d04b2bf1f294698f70
Allowlist v2 will change bp2build by automatically disabling rdeps of
unconvertible modules. Many bp2build tests create bp2build stub modules
without an implementation,
This CL changes setup of such tests to also contain a BUILD file with
"stub implementations" of equivalent targets, to keep these test targets
convertible.
To verify this change in-place, this CL removes `bp2build_available:
false` from these dependencies.
This is a test-only change for bp2build tests.
Bug: 285631638
Test: m bp2build
Change-Id: I489480cbc4158a416b7abf57c35a6e2bc2ad6173
Because we're going to start generating partition images for the
product, and the partitions will eventually be checked in, we want
them to be in sensible locations. And the platform should be there as
well so all the targets for a product are co-located.
Bug: 297269187
Test: m nothing && b build --config=android //build/bazel/examples/apex/minimal:build.bazel.examples.apex.minimal
Change-Id: Iaa25c44aa00295ada279d5fd49b5498bbafb89d5
This involves some minor changes to testing infrastructure.
This is a rollforward of aosp/2628496 with a couple of minor changes:
- In ParseBuildFiles, filter out all build files that are kept due
to ShouldKeepExistingBuildFileForDir
- Add some minor test infrastructure for StubbedBuildDefinitions, with a
couple of proof of concept tests used to demonstrate its usage. This
pattern will become immensely more common as we implement allowlist v2
(as we will need to update all tests which today simulate build
definitions that have missing deps)
Bug: 285631638
Fixes: 286545783
Test: bp2build.sh
Test: m nothing
Change-Id: I7c3a03b02098e39dd8e51d327482b440f294478f
This feature is obsolete.
This makes a large number of codepaths "dead code" (such as
module-specific implementations of ApiBp2build functionality). These
will be deleted in a followup CL.
Bug: 284029211
Test: Presubmits
Change-Id: Ib53b99f1fe8c24380d219caf44e9bb3b96724fa0
* changes:
Handle .proto files in different package for filegroups
Handle .proto files that end up in a different package
Allow creation of BazelTargets in a different directory
The current API restricts creation of targets to the directory of the
visited soong module. This CL proposes adding a `Dir` property in
`CommonAttributes` that can be used to create a bazel target in
a specific dir. The use case for this is to dynamically create
additional targets for proto_library that are adjacent to .proto files
(Bazel poses a strict requirement about proto_library being in the
same package as the .proto file, but Soong does not)
Usage is restricted to dirs that have an existing Android.bp file. There
are some places in bp2build where we use existence of Android.bp/BUILD
on filesystem to curate a compatible fully qualified path (e.g. headers).
If we use `CommonAttributes.Dir` to arbritraily create BUILD
files, then it might render those curated labels incompatible.
Test: go test ./bp2build
Change-Id: If9446700457eddfb389be9d9bde39087f67daa60
...instead of based on constraint settings.
Bug: 269577299
Test: m nothing and ./build/bazel/ci/bp2build.sh
Change-Id: Ib9caec79c92b8fd304e46be841de5612bd1637e3
This involves some minor changes to testing infrastructure.
Bug: 285631638
Fixes: 286545783
Test: unit test
Change-Id: If64ba29308d99e63a1cc5526feaf077f2cb14478
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
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
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
Create a
build/bazel/product_config/generated/products/<product_name>/BUILD
file that contains the platform definitions needed for
a particular product. Currently we just create it for the
current lunch target, but the idea is that eventually when
all product config is in starlark, all the products will
have their platform definitions in the tree at once.
Bug: 249685973
Test: Presubmits
Change-Id: I08c82ff28dcf62f09d3b1d2e3186a6b961e12f6e
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
Previously, it stored an android.Context (no pointer) which while it
worked (because the current contents are themselves pointers) it is
inconsistent with how the rest of the code references it and could
cause weird behavior if additional fields were added to the Context.
Test: m nothing
m bp2build
Change-Id: I9c70f925dde85e5b15431cc232b0c2eb6371ec6d
The generated Bazel workspace will only contain api specific targets.
This is feasible since these targets do not have any cross dependencies
with the targets in the bp2build workspace
The advantages of a new mode are
1. Does not pollute bp2build workspace with api targets
2. Does not block api targets with the current allowlist conversion
mechansims in bp2build
(In the future we might want to combine these two workspaces)
A Soong module type will generate a Bazel target if it implements
ApiProvider interface
Test: m apigen
Test: m nothing
Change-Id: I69c57ca6539f932e0ad554ce84a87fb7936fdba0
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
Add it to the `CommonAttributes` struct and handle it in fillCommonBp2BuildModuleAttrs
Bug: 190817312
Test: treehugger
Change-Id: I7b21056e680384d4046372ee844512029721026e
bazel_path conversion would treat "./" as a package boundary
which would be incorrect
Bug: b/243072036
Test: unit test build_conversion_test.go and `m libc`
Change-Id: I0fc44d2fd7a4270442c8755219a11fd585244c5c
Add a filter for cyclic references in required module names in bp2build.
Test: CI
Bug: 247985196
Bug: 225291837
Fixes: 234748998
Change-Id: Id1cfd0b2e5f217cdb01218ec3bbe11d5070cc9df
For directories without an Android.bp file, if they contain a merged
checked in BUILD file, it becomes a package boundary in the symlink
forest. However, the current glob expansion is only aware of Android.bp
files, but not merged BUILD files, so it generates glob expansions
incorrectly for files that cross the package boundary.
This CL fixes that by making the package boundary function aware of the
keepExistingBuildFile allowlist. See the new test cases for example.
Also stop using the same global bp2buildConfig for every test case to
allow each test to define their own bp2build allowlists.
Bug: 185358476
Test: new unit tests
Change-Id: Ifcd1283480a09a642ef4343e5bbc599583524577
This is to support the migration of conversion tests to be next
to the files they're testing
Bug: 242070498
Test: m bp2build
Change-Id: I66243d420743273e7ebad70886cfe690740182c4
Since we are putting conversion tests in the same
package as the module being converted from now on
Test: m bp2build
Change-Id: Ied53589d497fef70bfa11d8f6067459c9a50cd72
It's not needed anymore since aosp/2197837,
it should've been removed in that cl but I forgot.
Bug: 234167862
Test: ./build/bazel/ci/bp2build.sh
Change-Id: I3d67a6e1894ad401525070ad37d3158708898306
Instead of a StringListAttribute of length 1,
introduce a more appropriately reduced StringAttribute
so that e.g. `select`s work properly
Test: new cases in TestGenerateBazelTargetModules
Change-Id: I0ae0e4a51e39f85caf55b0d00459222ede6de79c
bp2buildTestCase
attrNameToString
runBp2BuildTestCase
makeBazelTargetNoRestrictions
The testing framework defined in the bp2build package can only be used
from within the package because many common testing functions are
private to the package. This prevents modules defined in Soong
plugins (e.g. system/tools/aidl/build) from testing bp2build conversions.
Test: go test ./bp2build
Change-Id: Ia867081327c5181d04687b13c4550e68e6a11f86
By default, most module types are only enabled for device. Converting
this behavior and host_supported/device_supported properties allows us
to skip building incompatible targets.
Test: soong tests
Test: bp2build.sh
Change-Id: If1da523b4cc8c4cbf2bb26da063d9923b662cc32
This is to avoid having it hardcoded in a fork of the
py_library rule.
Most import attributes should just be set to ".", but
our previous solution always hardcoded it to ".." instead,
for ndkstubgen. ndkstubgen uses pkg_path: "ndkstubgen",
i.e., it set pkg_path to the name of the folder that
contained the Android.bp file. In this specific scenario,
imports = ".." works. Recreate that behavior here as well,
because we don't handle pkg_path properly yet.
Fixes: 233081071
Test: build/bazel/ci/bp2build.sh
Change-Id: Ib5e6a8edf428c74d4b5947f0ec53a2151001367a
To make testing easier, refactor existing module-global variables into a
struct that can be mocked.
Test: build/bazel/bp2build.go
Change-Id: I9d177677644ea743641a745b1839a3a8b29f902a
Adds support to warn rather than error about missing deps in order to
suport modules in build/soong with deps outside of build/sooong in
bp2build integration tests.
Test: build/bazel/ci/bp2build.sh
Change-Id: I1282bccd37a3fc9f33555d34e68d7f0873d8272c
Each conversion required defining a separate mutator, which will each
operate on _all_ modules and requires each to repeat checks whether the
mutator should operator. Instead, we introduce a single mutator and
modules can define a ConvertWithBp2build to implement bp2build
conversion for that module.
Test: bp2build.sh
Bug: 183079158
Change-Id: I99d4b51f441c2903879092c5b56313d606d4338d
Previously, could not set an empty string as a value of an attribute;
however, this is necessary in some cases. To not unnecessarily create an
empty string, use string pointers for attributes rather than strings.
Test: go test bp2build tests
Change-Id: I03b3a3567452d455246d22d81f86c317d06b7c39
Moves to specifying attributes as a map, such at it is possible to add
additional attributes conditionally. This is in particular useful once
supporting the `enabled` property which will add
`target_compatible_with`
Test: go test soong tests
Change-Id: Iade8eed1ce3acb1d1712a9ee3119d9ae59675624
Soong supports additional arch-variant targets based on arch/os aside
from strictly arch/os names. Handle the unconverted cases based solely
on arch/os.
Test: build/bazel/ci/bp2build.sh
Change-Id: I8dc987b1aa4a4ea646dd5b03a94b84297ba6113a
Introduce `commonAttributes` & `fillCommonBp2BuildModuleAttrs used in
CreateBazelTargetModule
Adapt `bp2BuildInfo` to use `commonAttrs` instead of `Name`.
And thus also all downstream users of `CreateBazelTargetModule`.
As initial user, the Soong `required` property will be
translated to Bazel's `data`.
Bug: 198146582, 196091467
Test: build_converstion_test.go:TestCommonBp2BuildModuleAttrs
Test: go test
Test: mixed_{libc,droid}.sh
Change-Id: Ib500e40f7e2cb48c459f1ebe3188962fc41ec124
Support three options for converting modules with unconverted
dependencies
1. (default) Warn when converting a module if it has unconverted deps.
2. Error when encountering a module with unconverted deps. (not hooked
up yet)
Test: build/bazel/ci/bp2build.sh
Test: build/bazel/ci/mixed_libc.sh
Test: BP2BUILD_ERROR_UNCONVERTED=1 build/bazel/ci/bp2build.sh with
unconverted deps -- get appropriate error
Bug: 181155349
Change-Id: Ifaabf0cd2e43e963366dc137159c705294165c3d
For structs that are embedded, Blueprint does not nest under the
embedded name, flattening them into the original struct for blueprint
files (e.g.
9fd2ed93df:proptools/unpack_test.go;l=402-431;drc=3adb2409648d6f8b25354ac47f083dae87731f10).
We should do the same for bp2build.
This will also allow us to embed structs for bp2build conversion
allowing more reuse.
Test: go test bp2build tests
Change-Id: I9ce088462adaf59bffa80bea76cd488e31f98e9d
with the same name.
Also add capability to test for errors raised in bp2build mutators /
contexts.
This CL does two things to filegroups:
1) If the filegroup has only 1 source file with the same name as itself,
don't generate a filegroup target. Instead, dependents will depend
directly on the Bazel file target instead.
2) If the filegroup has more than 1 source file and 1 of them has the
same name as itself, the bp2build mutator will error out. If bp2build
on CI passes, it means that the source tree / product we're testing
against does not have such a case (which seems to be true for most
source trees).
Either way, this will allow us to be unblocked for most of the errant
filegroups (case 1) in the tree.
Test: CI
Test: New test cases in filegroup_conversion_test.go
Fixes: 194762573
Change-Id: I830c53efc8808569afe3c5f9f08436855bcdafed
A performance improvement for bp2build as Blueprint/Soong no longer have
the overhead of additional modules. The creation of these modules
results in:
* traversal of additional modules for each subsequent mutator
* synchronization over a go channel to collect newly created modules:
https://cs.android.com/android/platform/superproject/+/master:build/blueprint/context.go;l=2594,2600;drc=1602226f23181b8c3fbfcaf3358f0297e839d7d3
We avoid both of these by storing the information directly in the
underlying module.
Also as a fringe benefit, removes some necessary boilerplate for
conversion.
For benchmarks, reduces runtime ~1% for 1% converted, ~24% for 100%
converted. See more: go/benchmarks-for-https:-r.android.com-1792714
Test: ran benchmarks/tests in bp2build
Test: build/bazel/ci/bp2build.sh
Change-Id: Ie9273b8cbab5bc6edac1728067ce184382feb211
