For explicit values of compile_multilib (e.g. 32 or 64), add an
incompatibilty constraint for the arches that do not have the correct
bitness.
Test: go test ./bp2build
Bug: 299135307
Change-Id: I4cd997de6804a5c6d89086d740f773936db1cab9
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
A single proto providing directory can be used by multiple soong modules. Some of these
can be
1. Host specific
2. Device specific
3. Both host and device
Since the generated proto_library can have 1:many mapping, it should
have an empty target_compatible_with. Compatiblity will be enforced at
the top-level {cc|java|python}_proto_library.
(This is a followup to aosp/2727054 which did not handle this correctly)
Test: Added a unit test
Change-Id: I09b3def70e3d043fd8ba0d1eb4ffff1910f097d1
Now that aquery includes this information.
Also added rm -f $out to some rules, because since they write files
by shell redirection, if the file existed before and was executable,
they wouldn't make the file non-executable and visa versa.
Fixes: 297366783
Test: m bazel_sandwich
Change-Id: Ie5b6c4275b162601f51deaec9912eea4be16988d
There is no one actively using mixed sepolicy build, and it made
sepolicy codes too complicated. As we are deprecating mixed build,
removing such code for cleanup.
Bug: 298305798
Test: boot cuttlefish
Change-Id: Icb5071eb1378f8ed83568e4445d7b4d33e29bc46
createProtoLibraryTargetsForIncludeDirs uses a lock-protected plain map
to see if a directory has been handled previously during concurrent visits
of modules in bp2build.
From golang's docs https://pkg.go.dev/sync#Map, replacing sync.Mutex
with sync.Map will be faster in this use case since the keys (directores
here) are written just once but read many times.
Test: m bp2build
Change-Id: Ia2a471b4db5d2890fa6048bc05a17cebc5f686af
This should hopefully fix an intermittent flake in bp2build, which is
now run by default.
Test: go build ./android
Change-Id: Ic257a34448ab323df1680cf1990b087ed415a592
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
These deps are not depdendent on libaconfig_protos (rust_protobuf_host) and rust_proc_macro modules.
Test: b build //external/rust/crates/...
Bug: 295910506
Change-Id: I1c6058d029c2d475bd760ae9497fe78343a13882
This change provides support for prebuilt incremental platform API (i.e.
API changes associated with a QPR, as opposed to a major dessert
releas).
This feature is provided via the existing prebuilt_apis module with the
introduction of a new attribute:
allow_incremental_platform_api
While typical platform prebuilt APIs are presumed to be under a
directory structure that follows the pattern:
<version>/<scope>/<module>.jar
<version>/<scope>/api/<module>.txt
Where <version> is limited to a single integer signifying the API level.
For modules where allow_incremental_platform_api is set to 'true' (false
by default) the pattern is the same, however <version> is presumed to be
of the form MM.m, where MM aligns with the existing API level and m
signifies the incremental release (e.g. QPR).
Bug: b/280790094
Test: platform build check with both incremental & non-incremental API
cd build/soong && go test ./java
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:eee6995093485497bc29cdce01c2a86765ffb4eb)
Change-Id: I67e293006ccfa210d0dcc0a294db894632f1b6cb
Rather than PRODUCT_SHIPPING_API_LEVEL, use board api level
(BOARD_API_LEVEL or BOARD_SHIPPING_API_LEVEL) to determine whether we
check coredomain violations or not.
Also provides a Makefile variable to override the flag, for targets that
want to turn on the check optionally.
Bug: 280547417
Test: see build command of vendor_seapp_contexts
Change-Id: Ic7c4a53d0df0cccd45eb699e236a92c8c0bc2d56
* 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
Also make -test.sh files executable, while we wait for a bazel update
that will tell us which FileWrite actions should be executable.
Bug: 297268692
Test: m bazel_sandwich
Change-Id: I60498577ba12813bff8bbdbc1b997ea4addefd17
The module introduced in aosp/2722136 depends on `delta_generator`,
which is a module defined in directory that is not bp2build default
allowed, causing bp2build failure. Therefore, denylist the module to
resolve breakage.
Test: TH & abtd
Change-Id: I313239d82d384ec7de8167aa385806ebde02d2c8
Bug: 297269308
aosp/2719934 lists tradefed as libs, causing bp2build failure as the
module is not converted to bazel. Thus, denylist the module to resolve
bp2build failure
Test: TH & ABTD
Bug: 297039097
Change-Id: I41f2673636a7564fd6fb75ae97b93613f9098365