This change moves java_api_library modules that were previously defined
in build/orchestrator closer to where their from-source equivalents are
defined.
Test: m (default to from-text stub build)
Bug: 274805756
Merged-In: If66b5bba719bb389a69f2353d2218a89b2b96b90
Change-Id: If66b5bba719bb389a69f2353d2218a89b2b96b90
Using Label struct as the map key causes issues because it contains
OriginalModuleName. The same module will have a different value for this
property when called from inside a soong namespace vs from outside.
If there are dups, we can just choose the first one. OriginalModuleName
is often used with ModuleFromName, and that function panics if there are
modules with the same name in two separate soong namespaces
Test: go test ./bp2build ./bazel
Change-Id: I2ee33efab03016a72f1eea99cb958b6198baeca2
Mostly so that genrules can have their command qualified on a product
variable.
Bug: 295910468
Test: m nothing
Change-Id: I28cc18a1b3b00368f4768a1326259a656ce970ec
We encountered a duplicate sources bug in python proto generation
because we're only using the base name. This CL makes it use the
entire path to avoid this.
Fixes: 295333879
Test: Presubmits
Change-Id: I4ab821508cd5979bd595e327c1ccd3d68110fba6
- Hide universal binary dependency for rust
Without a darwin_arm64 libstd prebuilt, many rust binaries are not
possible to build as a universal binary anyway. This fixes an
intermediate error with compiling rust FFI targets, where C++ shared
library dependencies for both architectures were combined into the same
linker command.
There is still an outstanding problem with C++ executable targets that
include rust FFI library targets, as the rust FFI library targets
fail to find a proper libstd to build the arm64 side of the universal
executable.
- Use dynamic_lib instead of soname
This matches similar logic in cc/library.go : linkerFlags for including
shared libraries.
Bug: 291830024
Test: m libkmr_cf_ffi (when enabled for darwin)
Change-Id: I1d6b6a7855c6649b93ab6592ea43b17c6e37b3a3
Because enabling ThinLTO makes some constructor functions not called
in arm64 executables.
Bug: 295944813
Test: build
Change-Id: Ic0cab5fd80aa86d0d9ca1131564b747a445c6e46
Since full_api_surface_libs extract class files instead of srcjar file,
full_api_surface_stub can be replace with android_*_stubs_current,
instead of the api_library android_*_stubs_current.from-text.
Functionally, the class files of the two modules are identical (in
from-text stub build), but depending on the from-text java_api_library
leads to missing dependency errors in partial branches (especially ART
branches). To resolve this problem, make sdk_library generated
api_library depend on the missing dependency handled
android_*_stubs_current.
Since android_module_lib_stubs_current.from-text does not have its
from-source equivalent, this can remain as dependency as the module is
moved to build/soong in aosp/2674196
Test: m (default to from-text stub build)
Bug: 274805756
Change-Id: Ic8bbd25252e5f9f1dc7c059ce6b00a951188985d
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
For device build, rust defaults to dylib linkage for rustlibs deps. `dylibs` prop was provided for flexibility.
By removing it, we're enforcing users to either use the default linkage (dylibs for device and rlibs for host) or rlibs prop explicitly. This means no dylibs for host modules. This makes sense because host modules always uses rlib linkage against libstd. The flexibility with dylibs prop opened room for linkage collisions because the dependencies don't link against libstd the same way.
Test: go test
Change-Id: I2fc221daa8a9bb42bdcf6d9823c723a4ddabe7b5
`Previous_api` is used to migrate nullness information in metalava (i.e.
convert @Nullable and @NonNull to @RecentlyNullable and @RecentlyNonNull
for some methods). The input is required to generate loosely equivalent
from-text stubs.
Test: m && compare nullness annotations between from-source stubs and from-text stubs
Bug: 293962901
Change-Id: Ic7a0868415fdb2c65d0d472e527fe73280b7651d
legacy.i18n.module.platform.api, stable.i18n.module.platform.api and
conscrypt.module.platform.api contributes to api surfaces, but the
corresponding stub libraries were being generated from source during
from-text stub build. This discrepancy may lead to hiddenapi failure.
Thus, enable these modules to be built from txt files during from-text
stub build.
Test: m
Bug: 274805756
Change-Id: I940dc8484b210bb8aea57ead1055983be7cdf5ec
Set Bazel_module.Label for modules that are migrated and
Bazel_module.Bp2build_available: false for types that are not converted.
Test: CI
Test: m json-module-graph and inspect
Change-Id: I47b82d5055cdfd5ba6b2878e88f39447f1a50223
This change enables scopeOrderedSourceFileNames to be not computed
everytime when the function is called, but instead is computed once.
Test: m
Bug: 295429988
Change-Id: I33846cdb7a750e44e45049dbd342aa6ab8b70c4c
The orderfile use flags are unused as cflags causing warnings which becomes errors in some order file builds
In addition, I fixed the test cases so it only looks at ldflags not cflags for orderfile use flags.
Test: mma build/soong
Output: #### build completed successfully (05:14 (mm:ss)) ####
Change-Id: I2a2d846d6688fd5256cf753267c000ff054d56f1
That will allow the format of a file to be changed by simply modifying
the signature format in the current API file (e.g. from `2.0` to `3.0`)
and then running `m update-api` and it will just update the current API
file (and the corresponding removed API file).
Bug: 295577788
Test: m checkapi && m update-api
# Also did as described above and modified the
# `libcore/api/current.txt` file from `2.0` to `3.0` and ran
# `m update-api` and checked that only that file and the
# corresponding `removed.text` file was changed.
Change-Id: I20c9bc151677502cf09b0c06fb442fd385caccdd
Recent changes in metalava (aosp/2704325) enforces api files passed as
inputs to generate stubs from txt to be sorted in the order from the
narrower api scope to the wider api scope. In order to comply with this
change, all api files passed as inputs to metalava invocations need to
be sorted in the respective order.
Test: m out/soong/.intermediates/packages/modules/IPsec/tests/cts/CtsIkeTestCases/android_common/e10894d3da5db41239526c9048962355/javac/CtsIkeTestCases.jar --build-from-text-stub --skip-soong-tests (Failing module from incorrect class hierarchy when building from text stub)
Bug: 295429988
Change-Id: I1eb1f4bf8fa34fd7dc8a0e4c04aa056258a975c5
- ARM 32-bit targets will be built with 4096 ELF alignment.
- ARM 32-bit targets will only support 4K Page sizes.
- ARM 32-bit targets won't be page agnostic.
Test: source build/envsetup.sh
lunch aosp_cf_x86_64_phone
m
Bug: 295550555
Change-Id: I61cc45fa5f2ea18c494dfc9a0ca44cf9b694dfa3
