Implement APEX stub of API surface so any stub can be replaced with API
surface when APEX stub interface is required.
Unlike other stub interface, APEX stub can be decided if it should be
used after APEX postdeps mutator analyzes which modules should be
included in which APEX. To cover this, APEX stub is being added to the
dependency if the dependency should not be covered with LLNDK or NDK
stub, and APEX stub exists. From depsToPaths, if dependency to both
original module and API library exists, then it choose one of the
dependency and ignore the other.
To cover this logic, a new property is added to the api_surface :
apex_libs. This is introduced as it is difficult to
gather all api library with apex stub before DepsMutator.
Bug: 264963986
Test: cf_x86_64_phone_vendor build succeeded
Change-Id: I9f0b1f70968e32eba94d3e0d7bb1f4bb29ff2438
Rename export_headers of cc_api_variant as export_include_dirs, because
the property only supports header directory.
Bug: 244244438
Test: Cuttlefish vendor build succeeded
Change-Id: I6e1468f51694150c70d3b0def2917f0ba74f7ea0
Update cc build logic to support NDK variant of cc_api_variant. Any
cc_api_library with NDK variant of cc_api_variant would be treated as
similar with NDK library.
Bug: 259007436
Test: Cuttlefish vendor build succeeded
Change-Id: I75a7475f4fdcbac779f5aa64e76c60f94ea7ea1a
Define CcApiLibrary Variants for LLNDK. Each variant will be defined as
below.
cc_api_variant {
name: "libc",
variant: "llndk",
arch: {
x86_64: {
src: "libs/x86_64/libc.so",
},
...
},
}
And CcApiLibrary will be marked to use this variant as below.
cc_api_library {
name: "libc",
...
variants: [
"llndk",
...
]
}
Soong will replace source of libc cc_api_library as src from
cc_api_variant during build time.
Bug: 244244438
Test: cf vendor build succeeded with LLNDK variants
Change-Id: I317ed1f558beb1f82f9f2d70811fa8f765bcad2b
The current combined multi-tree build graph is not accurate. A vendor.c
file currently does not have a dependency on the assembled .h file in
multi-tree out. Previous successful builds of
`multitree_build vendor/vendorimage` were a happy
coincidence (presumably because the actions which copy the .h files from
a speciific inner tree to out/ are at the bottom of the build graph).
Fix this by exporting `cc_api_library.src` to be an order only
dependency of its rdeps (both compile and link). Making an .so file an
order only dependency of _compilation_ is probably confusing, but I
think it will be less confusing than the other alternative I could think
of (creating .timestamp files for each api_surface include dir and
creating phony targets to make them available from top-level to chdir'd
inner tree)
Test: go test ./cc
Test: orchestrator/prebuilts/build-tools/linux-x86/bin/nsjail --config
out/nsjail.cfg --
orchestrator/prebuilts/build-tools/linux-x86/bin/ninja -f
out/multitree.ninja -t path
vendor/out/soong/.intermediates/external/angle/angle_common/android_arm64_armv8-a_cortex-a53_static/obj/external/angle/src/common/android_util.o
out/api_surfaces/vendorapi/current/libc/libc_headers.contribution.androidos_include/features.h
(Path did not exist before this CL)
Change-Id: I74391100f2108993448004019eeba6456af0c12a
There are some module definitions which are implemented for the proof of
concept, but these modules are not in use now. This change removes
unused module definitions to reduce confusion.
Bug: N/A
Test: m nothing passed
Change-Id: I9b8efbc368436eaef66a4e6557006e87c0c27713
Switch from `PathForModuleSrc` to `PathForSource`. The latter does not
check that the target path exists in the tree. This is necessary since
the prebuilt stub and header directories are not guaranteed to exist
when Soong analysis begins (Step 2a)
Build orchestrator will be responsible for putting these files in the
right place as part of Multi-tree ninja invocation (Step 4)
Test: go test ./cc
Change-Id: I27175a8440fca6bba21197b1e106a22b733da882
Introduce cc_api_library, which reflects imported API from other
inner-tree. This cc_api_library module type will later refer from
the other ninja module which generates stub library from the interface
description.
Tested environment :
* original libc definition has been removed temporarily, to ensure that
imported api stub library is being used from build
* Added new definition of libc as below
cc_api_library {
name: "libc",
arch: {
x86: {
src: "libs/x86/libc.so",
},
x86_64: {
src: "libs/x86_64/libc.so",
},
},
header_libs: [
"libc_headers",
],
export_header_lib_headers: ["libc_headers"],
min_sdk_version: "9",
vendor_available: true,
}
Bug: 236087698
Test: `ALLOW_MISSING_DEPENDENCIES=true m vendorimage` succeeded
Change-Id: I67070b0f3561aa2afd73b6c1c0fdf4255218baac
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
