This causes unnecessary spam when running
m nothing --no-skip-soong-tests.
Test: m nothing --no-skip-soong-tests
Change-Id: I4d893b3da47a9f79774c67274a84ff77be9c4811
The property is used to prefer the 32-bit variant of a dep over the
64-bit variant. If 64-bit variant is the only available one, it is
depended on.
This will be used to include 32-bit preferred modules like drmserver and
mediaserver in filesystem modules.
Bug: N/A
Test: go test ./... under soong/android
Change-Id: Ic7185eb2044c9987f8d1e9b6cf7f0dbd235cf04c
deps: ["foo"] + select(product_variable("debuggable") {
true: ["bar"],
default: [],
}),
returns ["foo", "bar"] on debuggable builds, and ["foo"] on user builds.
Bug: N/A
Test: go test ./...
Change-Id: I31ca22e69e3316e4007a36ae13c04c7e5c445907
With this change, the deps property in filesystem modules gather the
first target of the filesystem module only.
To gather dependencies across both targets, use multilib.both.deps
instead.
Bug: N/A
Test: go test ./...
Change-Id: Ie2ff0c48f08c61c8b219fc2c1540476ff8e4b1fc
Consider this dependency graph:
A --> B --> C
And let's assume that B is built into A (e.g. static_libs), while B -->
C is a runtime dependency (e.g. required).
We want to install C (but not B of course) when A gets installed.
However, before this change, it was not supported because the dependency
A -> B was not tracked in computeInstallDeps. One had to explicitly add
a A -> C dependency.
This change fixes the problem by introducing the new interface
SkipToTransitiveDepsTag. computeInstallDeps uses it to decide whether to
take all install files and packaging specs or only those from transitive
dependencies. In the above example, if the dependency A --> B implements
the new interface and returns true, B's transitive dependencies (i.e. C)
are added into A's transitive dependencies. B's outputs are not added.
Bug: N/A
Test: go test ./... under soong/android
Change-Id: I3ca03a21633883f320ecb9e5bc82eb134519cd88
This effectively undoes both If6c3ee82d588e2742c85cef7244c090c93f38b8e
and I682e4f1f477f3024f7719dfaa67006ef335e0640. SDK variants are now
installed again, which will fix unbundled builds of cc_test modules.
The platform variants used by com.android.virt are now packagable
even though they are not installable.
Fix the original problem in b/194403710 by adding a flag to platform
variants of modules in apexes that are not platform available, and
using that to prevent install and packaging dependencies. That
allows the HideFromMake flag to go back to being used for preventing
install dependencies but not packaging dependencies.
Test: TestPackagingWithSkipInstallDeps
Test: TestFileSystemShouldInstallCoreVariantIfTargetBuildAppsIsSet
Test: TestFileSystemShouldSkipApexLibraries
Bug: 194403710
Bug: 268582372
Fixes: 274443025
Change-Id: If5418df3ddbb940bd631caebdf38daa81e71f40e
This reverts commit 502da3987a.
Reason for revert: b/274195633
```
In file included from out/soong/installs-aosp_cf_x86_pasan.mk:134984:
In file included from out/soong/Android-aosp_cf_x86_pasan.mk:981696:
In file included from build/make/core/soong_cc_rust_prebuilt.mk:76:
build/make/core/base_rules.mk:342: error: packages/modules/Uwb/service/uci/jni: MODULE.TARGET.SHARED_LIBRARIES.libuwb_uci_jni_rust already defined by packages/modules/Uwb/service/uci/jni.
```
Change-Id: Ic1ea6969e54c23a7d126eb0fb47ab6f2e44ee965
Currently, non-apex variants of modules that are in apexes are not
exported to make unless they're apex_available to the platform. This
means that you can't `m` those modules directly.
However, there is a workaround in the apex androidmk implementation that
emits make rules for the removed modules, but just redirects them to
build the apex itself. We want to remove that, but one of the problems
with doing so is that you can no longer `m` many modules afterwards.
To fix that, unhide the apex's dependencies from make. To ensure they're
not installed, call SkipInstall() on them, and update SkipInstall() to
be more strict by setting `LOCAL_UNINSTALLABLE_MODULE := true`.
Bug: 254205429
Test: Presubmits
Change-Id: Ib971981559f3b642ce6be8890679e994e1b44be0
Currently, non-apex variants of modules that are in apexes are not
exported to make unless they're apex_available to the platform. This
means that you can't `m` those modules directly.
However, there is a workaround in the apex androidmk implementation that
emits make rules for the removed modules, but just redirects them to
build the apex itself. We want to remove that, but one of the problems
with doing so is that you can no longer `m` many modules afterwards.
To fix that, unhide the apex's dependencies from make. To ensure they're
not installed, call SkipInstall() on them, and update SkipInstall() to
be more strict by setting `LOCAL_UNINSTALLABLE_MODULE := true`.
Bug: 254205429
Test: Presubmits
Change-Id: Ib094feb2c437ad50d8319c58caa997759e7ce32f
This gives a PackageModule a chance to filter/customize the contents of
resulting package.
Bug: 225121718
Test: m (no changes)
Change-Id: I45505e8234dff42201dc40d4f038e7b08eea89f0
Gathering packaging items from "SkipInstall" deps doesn't make sense.
Bug: 194403710
Test: soong test
Test: m microdroid # microdroid shouldn't have libandroidicu
Change-Id: If6c3ee82d588e2742c85cef7244c090c93f38b8e
CopyDepsToZip() zips direct dependencies with tags implementing
PackagingItem interface.
Previously, it relied on InstallNeededDependencyTag which has a
different meaning.
- InstallNeededDependencyTag tells whether a dependency is required to
be installed together.
- PackagingItem tells whether a dependency (of PackagingBase) is
required to be packaged.
With the separation of InstallNeededDependencyTag and PackagingItem,
PackagingBase module can distinguish cases which were not available
before.(I = InstallNeededDependencyTag, P = PackagingItem)
a (PackagingBase module)
|
|`--(I)--> b
|
|`--(P)--> c --(I)--> d
|
`--(I/P)--> e
a's CopyDepsToZip(): [c, d, e]
Test: m nothing (packaging_test)
Change-Id: I71fce29b19b0f00dc394981bcf4240e9c1041c7a
Makes the method more generally usable as it can work with any
WritablePath not just OutputPath. Also, makes it independent of whether
PathForModuleOut() returns ModuleOutPath or OutputPath.
Bug: 179124768
Test: m nothing
Change-Id: I08e61a24722198aa92fa2f8a2d096b1a8bf9c5c2
android_filesystem is a multi targets module type inhering from
PackagingBase. Since it's a multi-targets module, it is mutated only for
the common arch and therefore arch-specific properties are NOT squashed
into the matching top level property (i.e. setArchProperties is no op).
As a result, the values set in arch.<arch>.deps property were ignored.
This fixes the issue by explicitly adding the properties in
arch-specific structs and reading the properties in the matching arch.
Also added a set of tests for non-multi-target modules.
Bug: N/A
Test: m
Change-Id: Ibd4b509e73fa1760cc38b3661a08f83a6f639705
aosp/1501613 has landed. The filtering hack is no longer needed.
Also, fixed a bug that the dependency to the dynamic linker is not
treated as install dep.
Bug: N/A
Test: `m hosttar` and compare the built cvd-host_package.tar.gz with and
without this change. There is no removed file.
Change-Id: I19ef64e10d34bc8be2592c5258505cd632c91af9
Previously, the dep tag used by PackagingBase was fixed, which prevented
some of its clients (e.g. cvd-host-package) from opting in to
android.InstallAlwaysNeededDependencyTag. Now, PackagingBase.AddDeps
accepts the dependency tag to use.
Also, dependencies toward rust dylib, rlib, and proc_macro are
configured to return true on InstallDepNeeded. This is required to
install shared_lib dependencies of the rust modules when they are
depended on by a rust binary.
Exempt-From-Owner-Approval: a trivial change after +2 from the owner.
This has to land ASAP as many users are affected by acloud being
unavailable.
Bug: N/A
Test: m
Test: acloud create --local-instance --local-image
Change-Id: If22aee7c6f314fcb03b9d4fe6901a2557f1e899c
PackagingBase is the base struct that implements the basic packaging
functionalities. Here, packaging means grouping dependencies into an
output file where the built artifacts from the dependencies are placed
in a directory-like structure in the output file. The exact format of
the output file is irrelevant; it could be a filesystem image, tar.gz,
zip, or whatever.
PackagingBase is responsible for traversing the dependencies and copying
their outputs under the package root directory, which is expected to be
provided by the module type that includes PackagingBase. Then the
concrete module type is expected to do final step of converting the
package root directory into the output file of specific format.
Bug: 159685774
Bug: 172414391
Test: m dist out/dist/cvd-host_package.tar.gz
Change-Id: I5446eee4834ce3b6f0f5843d93bb330a26d42fe3
