This changes makes bpf module type uses OutputFilesProvider,
instead of current OutputFileProducer for inter-module-
communication.
Test: CI
Bug: 339477385
Bug: 342406930
Change-Id: I85d1141e9f6583cc5427756107da99f56b0c7ea1
When a common-arch module (ex: phony) has the "required" dependencies on
native modules (ex: cc_library), both 32 and 64-bit variants of the
native modules are added as dependencies. This by itself is fine and
actually is intended, otherwise there's no way for us to install both
arch variants via required deps.
However, this imposes a problem when the common-arch module is depended
on by a filesystem module with compile_multilib: "first". Here, the
expectation is that only the first variant (64-bit) of the native module
is instaled, but in reality both variants are installed.
To handle this situation, make sure that the packaging routine filters
out packaging specs from unsupported architecture.
Bug: N/A
Test: go test ./... under soong/filesyste
Change-Id: Ie1ad5ace2e5d88e00183a115f4a76e5df87a8166
By setting aconfig_flags: true, soong filesystem module installs the
aconfig_flags.pb file to its etc directory.
We need to define aconfigFilePaths to ModuleBase to store the list of
aconfig file paths that is generated from the GenerateBuildActions().
The aconfigFilePaths are collected when build the filesystem module
to build the aconfig_flags.pb for the filesystem image.
Bug: 335363964
Test: compare the cache list with those generated from make.
Change-Id: Ia32b566bf43174e94b9e610b9503608c6b583899
So far, we have used `instalable: false` to avoid collision with the
other modules that are installed to the same path. A typical example was
<foo> and <foo>.microdroid. The latter is a modified version of the
former for the inclusion of the microdroid image. They however both have
the same instalation path (ex: system/bin) and stem (ex: foo) so that we
can reference them using the same path regardless of whether we are in
Android or microdroid.
However, the use of `installable: false` for the purpose is actually
incorrect, because `installable: false` also means, obviously, "this
module shouldn't be installed". The only reason this incorrect way has
worked is simply because packaging modules (ex: android_filesystem)
didn't respect the property when gathering the modules.
As packaging modules are now fixed to respect `installable: false`, we
need a correct way of avoiding the collision. `no_full_install: true` is
it.
If a module has this property set to true, it is never installed to the
full instal path like out/target/product/<partition>/... It can be
installed only via packaging modules.
Bug: 338160898
Test: m
Change-Id: Iee9be674951d0bf3d5e26432fcbae9afebb6007b
A PackagingSpec actually means either of two: an installation of a file
(i.e. putting the file on a filesystem image), or a simple gathering.
However, so far, the two different intents was not visible in
PackagingSpecs returns from TransitivePackagingSpecs().
With this change, the two different intents are recorded in
PackagingSpec. A PackagingSpec has a boolean field which records the
value of the SkipInstall() of the module where the PackagingSpec was
created from.
This could be used by a module like android_system_image which wants to
follow the "installation" semantic. For example, the module type doesn't
want to include a stub variant of a shared lib.
This change doesn't make use of the new field, yet.
Bug: 335506668
Test: go test ./...
Change-Id: If0106642a11ba804630df79b4c5ebd608a77a6b1
Also move EvaluateConfiguration() to a standalone configurationEvalutor
object, which can be constructed from a ModuleBase and a minimial
context. This allows us to evaluate configurable properties in
scenarios where we don't have much more than the module.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: I2d1c9f42a469c399f34c759410509aeae095becb
See the blueprint cl for more information.
Things still to do:
- Support selecting on product variables and
variants
- Test/Support property struct reflection tags
like arch_variant, path, and variant_prepend
- Test that selects combine well with existing
configurability mechanisms like arch:, target:,
multilib:, python's version:, etc.
Bug: 323382414
Test: go tests
Change-Id: If5d1ea1ad0c4ebabffaea91d62e1a1c6f926a793
symlink_outputs was added so bazel could run ninja files, but we
abanoned that approach in roboleaf, and then roboleaf was cancelled
entirely. Remove this feature so we're more compatible with upstream
ninja / n2.
Bug: 160568334
Test: Presubmits
Change-Id: Ic368c48dd01b68e51c471c3fe90d0c02c55956e9
Generate module_info.json for some Soong modules in Soong in order to
pass fewer properties to Kati, which can prevent Kati reanalysis when
some Android.bp changes are made.
Soong modules can export a ModuleInfoJSONProvider containing the
data that should be included in module-info.json. During the androidmk
singleton the providers are collected and written to a single JSON
file. Make then merges the Soong modules into its own modules.
For now, to keep the result as similar as possible to the
module-info.json currently being generated by Make, only modules that
are exported to Make are written to the Soong module-info.json.
Bug: 309006256
Test: Compare module-info.json
Change-Id: I996520eb48e04743d43ac11c9aba0f3ada7745de
Overriding android.ModuleContext's implementations of *Specific()
methods in cc.moduleContext and then passing that back to
android.PathForModuleInstall to affect the install path causes
problems if android.ModuleBase.GenerateBuildActions also tries
to call android.PathForModuleInstall directly with the
android.ModuleContext as it gets a different result.
Add InstallIn* methods to the android.Module interface, implement
default versions in android.ModuleBase, and override them in
cc.Module and rust.Module. Use them in android.PathsForModuleInstall
to allow the module to customize the behavior directly.
Test: TestInstallPartition
Change-Id: I7840e07eae34ac4f4d3490b021143d5f33a83626
To generate module-info.json in Soong for b/309006256 Soong needs to
know the test data paths. Moving test data installation into Soong will
also help later for test suite packaging.
Add ModuleContext.InstallTestData that installs the files listed in a
[]DataPath alongside the test. The files will also be passed to Make
to allow it to continue packaging them into the test suites for now.
Update the module types that are producing LOCAL_TEST_DATA entries
in their Android.mk files to go through InstallTestData instead.
Bug: 311428265
Test: atest --host toybox-gtests --test-timeout=120000
Change-Id: Ia8b964f86e584ea464667fd86a48d754d118bead
Installed files should only depend on other installed files, change
the deps arguments of the ctx.Install* methods from Paths to
InstallPaths.
Bug: 311428265
Test: builds
Change-Id: I1ebef60a943bdbe907744cc43aa985371ac56d32
Merged-In: I1ebef60a943bdbe907744cc43aa985371ac56d32
Move EarlyModuleContext, BaseModuleContext and ModuleContext out of
module.go and into early_module_context, base_module_context and
module_context.go respectively.
Test: builds
Change-Id: I52e6eb1589d1478233c1c55d770b395a16eaa1a3
