When sdk_version is unset, the build with fail with Bazel because
private APIs are do not build with Bazel at this time.
This instead prevents migrating the relevant target to Bazel in bp2build
Test: go tests
Change-Id: I31dabcf143de7933706d1b734ef21467a01b65e9
The fixes are
- Dedupe the dir list. Since we partition the proto srcs per pacakge and
then iterate the map, a single include directory was being listed
multiple times
- Drop target_compatible_with from these proto_library targets. The
compatibility will be enforced at the top-level <lang>_proto_library.
Test: Added a unit test
Change-Id: Ia18c0f8c495585010fd4e372092afe80c5d8290c
Since this is a one-off just for building libprotobuf that will be removed when we handle cargo output more generically (b/297364081), I didn't write a unit test for this CL.
Test: b build //external/rust/crates/protobuf:libprotobuf
Bug: 295925256
Change-Id: I00cf44d54be27a09c184a96c13b250a2e54e2d10
The prebuilt_ prefix was removed before writing converted modules, which
causes false positives when a prebuilt and from source module exist with
the same name but only one has been converted
Test: b run //build/bazel/scripts/bp2build_progress:bp2build_progress \
-- report -m core-lambda-stubs-for-system-modules
Change-Id: Id00099780fb6af9fffcf745b509116a66bac8756
* changes:
Handle proto.include_dirs in bp2build for py
Add proto.local_include_dirs support in bp2build
Add manual tag to proto_library at the root package
If a python_library uses a pkg_path foo/bar, then the proto srcs in
that libray need to import the dep .proto as foo/bar/proto.proto.
This behavior is restricted to python modules. To implement this is in
bp2build, this CL creates a new interface with a single method
`PkgPath`. Only python module structs implement this interface, and
this method is only available during bp2build
Test: Added a bp2build unit test
Test: TH
Change-Id: If8d207c0b321f75337a053795826b283a5eaaf46
This is a followup to aosp/2711093 which added support for
proto.include_dirs. local_include_dirs is simlar, except that is
relative to the module directory.
Test: go test ./bp2build
Bug: 285140726
Change-Id: I32ddc7371048672d6935f827c8aee9d767305e2c
This is a fix similar to aosp/2707793. This adds manual tags to the
top-level proto_library created in the root package, plus any
dynamically created proto_library targets for proto.include_dirs. These
proto_library targets might not specify their deps correctly and might
be unbuildable.
(We need to keep these targets because they provide a ProtoInfo for
cc/java/py source gen)
Test: go test ./bp2build
Change-Id: Ic00f05186327fcfcc8d33a0a2c0891ed619b7acb
The config constant is consumed by rust toolchain implemented in aosp/2709668.
Bug: 295918553
Test: go test
Change-Id: I0a28a802ad28f6ee24dfb1b5bdab72094534ae04
Since we no longer support "zip" APEX, we don't need "host" support.
For example, we don't need go/python binary support.
Bug: 279835185
Test: m
Change-Id: I6e8d2b205e42662f31866dc9ac7507524effd144
expandSrcsForBazel always prefixed : in OriginalModuleName. The
exceptions to this are filegroups that appear in a different soong
namespace. For these cases, we were not correctly substituting the soong
module name with the equivalent bazel label.
Test: go test ./bp2build
Change-Id: If090f3f8819835177c1f4d191b3eef6bb6e30ace
There are three types of tests, deviceless tests, device-driven tests
and host-driven device tests. But currently we don't have information
to get the type of a test and can't generate test targets on desired
types.
Test: b test //platform_testing/tests/example/native:hello_world_test
Test: b test //packages/modules/adb:adbd_test
Bug: 296312548
Change-Id: I3f022ef769636d508e055477623a4d1a6a1d9044
Soong's proto.include_dirs becomes the -I path for aprotoc cpp code
generation. This does not translate well to Bazel because it runs this
action in a sandbox. Even if we construct an -I path, the .proto files
will not be there. This CL attempts to handle this kind of dependency
automatically via bp2build.
For this hypothetical example
```
foo.proto # contains `import bar.proto"
Android.bp # cc_library {srcs:"foo.proto", p.include_dirs:["subdir"]},
subdir/bar.proto
```
Implementation details for CcProtoGen of foo
- Glob the labels of .proto files for each includeDir, and create a
proto_library that encapsulates them.
- Since Bazel poses a contraint that proto_library target needs to be
in the same pacakge as the .proto file, the proto_library might be created
in a subdirectory with an import_prefix
- Add bar's proto_library as transitive deps of foo's cc_proto_library.
This will be added to -I during aprotoc. We cannot add them to `deps`,
otherwise bar's symbols will be statically linked into foo's .a
file.
Implementation details for clang compile of foo
At the end of CcProtoGen, we have converted foo.proto
to .cpp/.h files. To compile them to .a files, we need the .h files
generated from bar.proto. Soong specifies this at the
top-level cc_library soong module, so add those deps as the
implementation deps for clang compile.
(Will add support for java in a follow-up CL)
Test: go test ./bp2build
Test: built some internal modules that were previously blocked by this
Bug: 285140726
Change-Id: I7e1f9f0d1b1ba916a7ba8278f6cfb342b381d695
Mostly so that genrules can have their command qualified on a product
variable.
Bug: 295910468
Test: m nothing
Change-Id: I28cc18a1b3b00368f4768a1326259a656ce970ec
This is a fix for aosp/2693190 that handled .proto files that end up in
different bazel packages. It did it by creating proto_library targets in
the correct bazel package.
Changing the granularity causes issues if the the new proto_library in
the subpackage imports a .proto file from a parent package or a
different package. e.g.
```
tmp
├── foo.proto
└── subdir/import_foo.proto # contains an `import "foo.proto"`
└── subdir/Android.bp # package boundary
├── Android.bp # contains a cc_library with foo.proto and
# subdir/import_foo.proto
```
At ToT, the ProtoInfo we provide to CcProtoGen is correct, but the
proto_library in subdir/BUILD will not compile because it does not have
a dep on the proto_library in ./BUILD
This CL creates a workaround by adding `manual` to the proto_library
targets. This CL is based on the assumption that the buildable unit in
bp2build is cc_library_*, and not proto_library necessarily (atleast
till we do a manual/automated cleanup)
Test: Created an integration test in build/bazel
Test: go test ./bp2build
Bug: 292583584
Bug: 246997908
Change-Id: I73120be2411967cb144f37ed4417f76ecf1a6ffa
So that users can use soong config variables / product variables
to adjust a genrule's command.
Bug: 295910468
Test: m nothing
Change-Id: I9fedf8d5d52e515c3fdb913411ce1b3fecb7ba81
Protos in another directory were using import prefix, which was
prepending the repository-relative path with the value, instead, we want
to strip the prefix of the directory of the module the protos were used
in such that they can be referenced at the appropriate relative path.
Reference on import_prefix:
https://bazel.build/reference/be/protocol-buffer#proto_library.import_prefix
Test: b build //packages/modules/adb:libfastdeploy_host
Change-Id: If050b0f5fc5103bd9cc5a99703bd604325aa4204
In this Android.bp file
```
my_cc_defaults {
enabled: false,
soong_config_variables: {
my_bool_variable: {
conditions_default: {enabled: false},
}
}
}
```
The inner enabled: false is a no-op because the top-level enabled is
false. Currently, bp2build will raise an exception for this Android.bp
file.
However, it does not need to. `productVariableConfigEnableLabels` runs
only if the top-level enabled is false. If it sees enabled: false via
conditions_default, it should just ignore it since it is a no-op.
Test: go test ./bp2build
Bug: 210546943
Change-Id: I816f209eaf21de65ddfbc2893e5255be94bcaa11
