There was infrastructure to export ninja variables to bazel. Now that
the bazel migration is cancelled, we don't need it anymore.
Bug: 315353489
Test: m nothing
Change-Id: I298cc2ac7ebd004557be3b30d75f7357cab0b7a0
This relands aosp/3026027 with fixes for ndk_library. ndk_library
uses ctx.InstallFile to copy the stubs from an intermediate dir to
out/soong/ndk/sysroot/. The copy rule was created in
out/soong/installs-<product>.mk. This would cause issues when soong_ui
is run in `--soong-only` mode
To fix this, the cp rule is created entirely in soong. The stub library
is marked uninstallable to prevent creation of duplicate rules when
`--soong-only` mode is not used
Test: presubmits
Test: lunch ndk-trunk_staging-userdebug &&
ALLOW_MISSING_DEPENDENCIES=true build/soong/soong_ui.bash --soong-only
out/soong/ndk.timestamp
Change-Id: I6f8b87d88d8ca5ec9a3327e1f11e9aa654f8cdce
ndk_headers currently use ctx.Install to install headers in
out/soong/ndk/sysroot. The files are subsequently used to compile ndk
variants of cc libraries on host.
Since these headers are not actually installed on device, use android.Cp
to assemble the NDK sysroot. By itself, it should be a no-op, but
androd.Cp is more friendly with restricting the installation rules to
PRODUCT_PACKAGES.
To make it explicit that the sysroot is not a typical installation path,
this CL also modifies the type to OutputPath
Test: m
Bug: 332778109
Change-Id: I1131c3c764443cbaac525c6022cd09c47695d275
The tool that had the bug this disablement worked around is no longer in
use, and the current tool "works for me"...
Test: ran locally
Change-Id: I801da20a00f54a90777b99ea264d9ab420b7f942
LOCAL_STATIC_LIBRARIES, LOCAL_WHOLE_STATIC_LIBRARIES,
and LOCAL_HEADER_LIBRARIES are only exported to Make
so that it can generate module-info.json. Export
ModuleInfoJSONProvider from cc modules so that Soong can
generate the module-info.json entries, and remove the
properties from the generated Android.mk. This will prevent
Kati reanalysis when making some Android.bp changes.
Bug: 309006256
Test: Compare module-info.json
Test: Compare Kati's build.ninja
Change-Id: I6660f6802b9cea46eed553cac12f09a373eeb019
Remove the ConvertWithBp2build implementations from all the module
types, along with the related code.
Bug: 315353489
Test: m blueprint_tests
Change-Id: I212672286686a318893bc7348ddd5a5ec51e77a7
Currently NDK ABI monitoring is enabled by switching boolean flag in
soong code. When this flag is switched, it will enable ABI monitoring in
all release configurations at once.
This change moves the flag from soong code to the trunk-stable flags
framework ("build/release/build_flags.scl") that allows to enable it
only in specific configurations like "trunk-staging".
Test: TH
Bug: 156513478
Change-Id: Ibb810a834c0d756b22782b1a2d8ec5a5e575a4b3
(This CL is a cleanup, and should be a no-op)
Currently we support three variations of cc api stubs.
1. publicapi stubs, i.e. ndk stubs (empty additional args to ndkstubgen)
2. module-libapi stubs that are also an ndk library (--systemapi --apex)
3. module-libapi stubs that are not an ndk library (--systemapi --apex
--no-ndk)
ndk_libs.bzl was used to differentiate between (2) and (3). This creates
an additional layer of indirection - users will need to modify this
external .bzl file if they would like to add a library to an ndk.
Replace this with an explicit atttibute in cc_stub_suite macro for better UX.
Test: go test ./bp2build
Test: b test //build/bazel/rules/cc:cc_stub_library_tests (added in
sibling CL)
Bug: 299501496
Change-Id: Idd3579e8013bae7a1740534f90d2767df5bac1a5
Just knowing it failed is pretty useless. Tell people how to update
the ABI dumps.
Bug: http://b/156513478#comment43
Test: m ndk # after breaking the ABI
Change-Id: I7ed6a0acf2d1fbd942410678fc6aba2afbc5a2b6
This is the bulk of the "allowlist v2" feature. It will disable bp2build
generation for modules which have transitive dependencies without a
bazel build definition.
This CL includes this mutator, but doesn't register it as a bp2build
mutator (outside of a few unit tests). This allows us to easily iterate
on completion of this feature and ensure there are no launch blockers
before we finalize the change in AOSP.
Bug: 285631638
Test: Unit tests
Change-Id: Ifb0a079c409ca19b02cafa3fab2efa0d3deebc50
Error message in case of not valid "nextAbiDump" included wrong
"prebuiltAbiDump.InvalidReason()". Refactor error message to include
"nextAbiDump.InvalidReason()" instead.
Change-Id: I2581734dd16649af2b282b3459f461658abd3d87
Signed-off-by: Aleksei Vetrov <vvvvvv@google.com>
This no-op refactoring facilitates some upcoming functional changes for
"bp2build allowlist v2". The work requires that the bp2build conversion
mutator be changed from a TopDown mutator to a BottomUp mutator.
Refactoring all bp2build-related methods so that they use Bp2buildMutatorContext
makes it easier to make this functional change without touching tens of
files and multiple projects.
Bug: 285631638
Test: m bp2build
Change-Id: I3d1ef3064146e959c6f0dc315350fc9764bf2bd2
NDK has two ABI checks:
1. Check that prebuilt ABI exactly matches compiled binaries.
2. Check that ABI of level X compatible with level X+1.
The second check used compiled binaries for level X and prebuilts for
level X+1. But this approach may confuse people, because ABI change will
be shown "reversed". For example, adding new field to ABI monitored
binary of level X would be shown as "removed" when compared to level X+1
prebuilt.
This change uses prebuilts for both level X and level X+1. Given, that
prebuilts are checked to match compiled binaries, this should be enough.
Change-Id: If942e4319744bc5a2674cdd65f6a6f664fdfaa7e
Signed-off-by: Aleksei Vetrov <vvvvvv@google.com>
ndk_libary will be converted to a cc_stub_suite target. Its api_surface
attribute will be publicapi
The headers corresponding to this stub target will be added in a followup bug
(tracked in b/300504837)
Bug: 298085502
Test: Added a unit test
Change-Id: If9745083b18e0bcf5ecb89229a0f709b949d401c
Collect all NDK exported headers paths into a file that is used to
detect public types that should be ABI monitored.
Assume that we have the following code in exported header:
typedef struct Context Context;
typedef struct Output {
...
} Output;
void DoSomething(Context* ctx, Output* output);
If none of public headers exported to end-users contain definition of
"struct Context", then "struct Context" layout and members shouldn't be
monitored. However we use DWARF information from a real library, which
may have access to the definition of "string Context" from
implementation headers, and it will leak to ABI.
STG tool doesn't access source and header files, only DWARF information
from compiled library. And the DWARF contains file name where a type is
defined. So we need a rule to build a list of paths to public headers,
so STG can distinguish private types from public and do not monitor
private types that are not accessible to library users.
Bug: 156513478
Test: development/tools/ndk/update_ndk_abi.sh with enabled canDumpAbi
Change-Id: I9fa41e73450a41379638debb3dc56f421e0fb870
Signed-off-by: Aleksei Vetrov <vvvvvv@google.com>
Now migration to STG is complete, hence remove the legacy extraction
mechanisms.
Bug: 156513478
Change-Id: I55b7626e2bfa78c9bb5157ade73d71a97597da72
Signed-off-by: Matthias Maennich <maennich@google.com>
Replace the abidw->stg pipeline by just stg for extraction directly from
ELF/DWARF. This is to migrate to STG entirely.
As a migration tooling, keep the existing method active via
`legacy_use_abidw` as a flag on ndk_library.
Bug: 156513478
Change-Id: Ideaa9908b31591f49f9a167cfa3f3d5c95d8b198
Signed-off-by: Matthias Maennich <maennich@google.com>
STG's native .stg format has been designed with version control in mind
as is the best format to represent STG's internal data representation.
Hence, migrate the ABI representation dump to .stg. That is done by
converting `abidw` extracted xml to stg at build time. STG has builtin
`abitidy` functionality, so `stg` can replace the prior `abitidy` step
to generate the final format.
Bug: 156513478
Change-Id: Ifcac8998ab899637a5d8c54f9e72d79d3e28ec52
Signed-off-by: Matthias Maennich <maennich@google.com>
To support export of NDK APIs in multi-tree, we added functionality to
generate Bazel targets of ndk related Soong module types. Since this use
case does not exist anymore, deprecate this to prevent bitrot
The removed code includes
- `ConvertWithApi2Build` implementation of these libraries, which
generates the Bazel targets in the synthetic `api_bp2build` workspace
- (api) bp2build unit tests for these module types
Test: go build ./cc
Bug: 284029211
Change-Id: Id3278fa119e0ab87f31f39a3783197a81b655e43
We've been fixing this up on the NDK build side for ages. The
platforms/ subdirectory is a legacy thing from very old NDKs. Fix the
install paths to match what the NDK actually uses. This both lets us
delete some code on the NDK side and also makes the platform's output
easier to consume directly without having to wait for an NDK release
(or even a canary).
Bug: None
Test: treehugger
Test: inspected out/soong/ndk/sysroot
Test: build/soong/scripts/build-ndk-prebuilts.sh, imported into NDK
Change-Id: I3c4e0ce6d7960ae0138d1cf803755e4f1e575631
We log an error message, but then carry on and attempt to use the invalid impl, which then panics.
Change-Id: I440cdf728cb32479a10cbaecc5aadbdd97f215de
The module types in scope of this conversion are
1. cc_library and cc_library_shared (non-null llndk or stubs prop)
2. cc_library_headers (all)
For (2), we need some postprocessing on the results of the parser
bp2BuildParseBaseProps. This is necessary because arch and os specific
API exports need to be flattened and added to the generateed API headers
target along NoConfigAxis
e.g.
```
The api equivalent of
cc_library_headers (
name = "lifoo",
deps = select({
"//build/bazel/platforms/arch:arm": ["arm_deps"],
"//build/bazel/platforms/arch:arm64": ["arm64_deps"],
}),
)
should be
cc_api_library_headers (
name = "lifoo",
deps = ["arm_deps", "arm64_deps"],
)
```
For (1), we also need to generate 1:many header api targets so that
arch-specific deps can propagate arch metadata to the top-level
api_domain rule
Test: go test ./bp2build
Test: go test ./cc
Change-Id: Ie40cba1ac8e89f290b3d926c190d5e93abd52859
This is a partial bp2build conversion that only emits the
cc_api_contribution target of ndk_library. We also need to convert this
to cc_stub_suite eventually to enable building vendor/product API
domains with Bazel
Also create an enum for the three known Multi-tree API surfaces (will
likely be expanded in the future)
Test: go test ./bp2build
Test: b cquery //bionic/libc:libc.ndk.contribution --output=starlark
--starlark:expr="providers(target)"
Change-Id: Idb24871ba20aae132b61eb31ef35c917cacae9e1
The new property will be used to determine the header file contributions of
ndk_library(s) to the Public API surface. This should be a no-op for
regular Soong builds.
This will be used by a future bp2build converter to populate
the BUILD files for Multi-tree `cc_api_contribution` targets
(Also noticed that sdk_test.go was never added to testSrcs, which this
CL should fix)
Test: go test ./cc
Test: TH
Change-Id: Ieea093e4aac68e341c6414b6cafe02c441643cdf
Looks like new versions of the toolchain have an error about mismatching
the definitions used in the stubs with the builtin definitions. Since we
don't care about this when building stubs, ignore it by disabling the
builtin definitions.
Bug: N/A
Test: Build platform with ToT LLVM compiler.
Change-Id: I4e449c5fb96d0d5442fd57a7fea02ba69463324b
This change contains a prototype implementation for multitree. Several
interfaces and modules are added.
1. Imported/Exported
Modules implementing Exportable interface can export artifacts to other
components. "imported_filegroup" modules can import generated artifacts from other exported modules.
2. Multitree metadata
It contains information about imported/exported modules in each
component, and can be generated via "m update-meta".
3. cc library stub
It's based on prototype stub libraries. It uses imported/exported
mechanism to expose a C API, with a map.txt file and header files.
Bug: 230448564
Test: m
Change-Id: Id7ff7618e2c630c5617a564d8b23b60a1cc9c8e8
abidw doesn't currently handle top-byte-ignore correctly. Disable ABI
dumping for those configs while we wait for a fix. We'll still have
ABI checking coverage from non-hwasan builds.
Bug: http://b/190554910
Test: treehugger
Change-Id: I0e29979f8c212c43e0d1beea737abcd7fd0119d7
Similar to `tidy_disabled_srcs`, a `tidy_timeout_srcs` list
can be used to include all source files that took long to compile
with clang-tidy. Files listed in `tidy_timeout_srcs` will not
be compiled by clang-tidy when `TIDY_TIMEOUT` is defined.
Bug: 201099167
Test: TIDY_TIME=90 make droid tidy-soong_subset
Change-Id: Ie0bfda66caae4445d10117ceefa1b5b8c1ecf256
Used as a supplement to C/C++ srcs to disable
clang-tidy for selected srcs, when a library
contains many files in srcs and only some of them
are too large to compile with clang-tidy.
Test: WITH_TIDY=1 TIDY_TIMEOUT=90 make tidy-soong
Bug: 198098397
Change-Id: Ib32eb0e46ddbc717999797717bfd8c57e182ee88
Both processes might consume a large amount of memory when analyzing
library ABIs. By chaining them via a pipe we keep the same
representation twice in memory. That can introduce a problematic peak
memory consumption. Hence, split them apart into separate rules that
depend on each other.
Bug: 191235788
Test: m out/soong/abi-dumps/ndk/28/x86_64/libc/abi.xml
Signed-off-by: Matthias Maennich <maennich@google.com>
Change-Id: Ia0264a5ede5b2c2a3c2e3fbe968c11d36acf33c2
I'm not sure why these targets are getting built as part of the sdk
build anyway, but we don't need them.
Test: treehugger
Bug: http://b/156513478
Bug: http://b/190394921
Change-Id: I1ea0e75f459ad7cad648f96b67a4f2424d36fda7
The local diffing behavior is currently flagged off so we can land
this in stages.
Test: pytest cc
Test: treehugger
Test: development/tools/update_ndk_abi.sh
Test: m ndk
Bug: http://b/156513478
Change-Id: Iccb314411bc74ea3ddfea8b85b0539709295f65a
This is unused and doesn't work with our current API review process
anyway (un-drafting an API won't be flagged for API council review).
Test: treehugger
Bug: None
Change-Id: I6d8fcc9885b82dac5ada7772d9e3fb9101524ece
Native bridge modules never need to build against NDK stubs, so
don't create SDK variants. Also clear the sdk_version property
for modules that don't have SDK variants so that later code doesn't
use it to trigger SDK behaviors.
Test: m checkbuild
Change-Id: I1920fa82e9fab06235f01a62624382efa16cc6e3
