You don't have to call module.ConfigurableEvaluator(ctx) if ctx is
already a ModuleContext, you only need to do that for more restricted
contexts like SingletonContext.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: I7612290d43dae7decfae283a341882d9016c98a3
The microdroid system image customizes dirs using soong config
variables, make it configurable so that selects can be used instead.
Bug: 342006386
Test: Presubmits
Change-Id: I4fbf4dc0a04ad1d1f6539476408606028390cd64
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
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
This change fixes a bug that required deps from native module to phony
module was ignored. It happened because addRequireDeps incorrectly
thought that both are native modules with different bitness (32->64),
which isn't.
Fix this by doing the bitness check only when both the current module
and the required module are native modules.
Bug: N/A
Test: go test ./... under build/soong/filesystem
Change-Id: I494ebc47e29001f174fa44d72809041f8ceffb0b
If build_logtags is set to true, etc/event-log-tags will be built by
collecting all logtags files from all dependencies.
Note that this is different from Makefile's current behavior that
collects all logtags files, including ones from uninstalled modules. But
the behavior is probably unintended, and ideally each partition image
should have its own logtags, rather than putting all tags to /system.
Bug: 336189540
Test: m aosp_cf_system_x86_64
Change-Id: I72b384cbb65e812af909eacd18799bd86f1dab13
With this change, filesystem modules (android_filesystem,
android_system_image, etc.) follow the installation semantic which means
output from modules which don't produce installable files (i.e. modules
that return false on IsSkipInstall()) are not included in the filesystem
module.
Note that this bug has been there since the beginning but didn't trigger
an error due to another bug (b/335506668) which allowed multiple
packaging specs to contribute to the same path. That bug prevented the
non-installable variant of a module (e.g. stub) from being installed
simply because because it was "luckly" clobbered by the installable
variant of the same module (e.g. impl lib).
Bug: 335506668
Test: go test ./...
Change-Id: I2a42d178701d74bf6ccc5f33ba33918f8c608d40
This fixes a bug that different PackagingSpecs having the same
installation path were silently allowed. Previously, a PackagingSpec
that comes the first for the given installation path won, effectively
eclipsing other PackagingSpecs destined for the same installation path.
Bug: 335506668
Test: go test ./...
Change-Id: Ia36f656e8364f95c4be78fff6e9dc16966307526
TestFileSystemShouldInstalCoreVariantIfTargetBuildAppIsSet is removed.
The test was originally introduced with aosp/2445946, but the change was
effectively reverted by aosp/2562192. The test however has been green as
a side effect of a bug (b/335506668) which will be fixed soon.
Bug: 335506668
Bug: 268582372
Test: N/A
Change-Id: I62f4746c605eba0b2f0037089a53d65922d65ef3
Previously, addRequiredDeps directly called RequiredModuleNames directly on
ModuleBase. As a result, it failed to correctly track the dependencies
for the modules which are overriding RequiredModuleNames. cc_* were
those.
Fixing this by calling RequiredModuleNames via the Module interface.
Bug: 321626681
Test: go test ./... under filesystem
Change-Id: I79de616606b88277da0b3e86b21316ee83e0ec71
android_systemimage_defaults is deleted and android_filesystem_defaults
is created so that we can have defaults not only for
android_system_image, but also all android_filesystem modules and its
derivatives.
Also, change adds a check which ensures that the partition_type of the
filesystem and its defaults are the same.
Bug: 330665150
Test: m
Change-Id: If635c794534ed89d264eaf7dfc406a8245b8e9f0
This change fixes a bug that the required property doesn't track
dependencies to modules whose arch is common.
Bug: 321000103
Bug: 321626681
Test: go test ./...
Change-Id: I3d2b3ad8cb2a9f1c5c3d5345bf05402a787f011a
By setting fsverity.inputs, android_filesystem can now generate
.fsv_meta and BuildManifest.apk. It has been done by Makefile because
Makefile is the only one knowing all installed files. But now
android_filesystem is aware of all artifacts, so we can move fsverity
metadata generation into Soong.
Bug: 330282551
Test: m aosp_cf_system_x86_64 and see output
Change-Id: Iae4dd83eaede960c263bfba537211df4ff4b36bd
ArchType.Multilib of native modules are either lib32 or lib64.
Arch-neural modules have "" not "common".
Bug: 321626681
Test: go test ./...
Change-Id: Ie7e6a5203e9f671487dbf32ea2343ada7407a28f
Current linker.config.pb from the package is generated with
auto-detected provide libs, but this misses require libs which can be
detected from module dependency. This change adds extra require libs to
linker.config.pb generated from system image so it can link with modules
outside of system image.
Bug: 324995772
Test: Link succeeded from Cuttlefish with soong defined system image
Change-Id: I8563ec9ddce2a1648cc9ee55704c9483e137b710
//visibility:any_system_partition, //visibility:any_vendor_partition,
etc.
Then, if a partition visibility rule is not specificed, but the module
is installed on a non-system partition via the `vendor: true` or other
properties, the visibility rule for that partition will be added by
default.
This is so that "any_partition" doesn't imply that modules could be put
on the vendor partition when they weren't designed for that, and so that
modules that do need to go on the vendor partition don't need to specify
both vendor: true and visibility:any_vendor_partition.
Eventually, the partition properties should be deprecated, and replaced
with just these visibility rules.
Bug: 321000103
Test: go tests
Change-Id: I24dba36bbc20921941f892480bf7c050e93827c6
So far, the installation of required modules were handled by Make. This
prevents us from implementing the module installation and packaging
entirely in Soong.
This CL is the first step towards that goal. Soong now correctly tracks
the dependencies and they are correctly returned by
TransitivePackagingSpecs(), which is used by packaging modules like
android_system_image.
Bug: 321626681
Test: build
Change-Id: I9192b5333ceaa0b7d1c5c4abeec2af62febcd976
If `include_make_built_files` is set to the name of a partition, the
make-built files from that partition will be incorperated into this
soong module. This is to ease the transition to soong built filesystems.
If any files are present in both the soong-built file list and the
make-built one, the soong ones will be preferred.
Bug: 329146343
Test: go test
Change-Id: I456b283e1189116e699ed75357cc056f5d217688
The end result is a directory that's passed to build_image, so zipping
and then unzipping image contents will unnecessarily slow things down.
Bug: 329146343
Test: m microdroid --no-skip-soong-tests
Change-Id: I98223c60e8144d6c707832fcc03ba8fe94467e7b
Use android.WriteFileRuleVerbatim instead of a custom RuleBuilder
with echo commands.
Test: m nothing --no-skip-soong-tests
Change-Id: I9734305cbb404fd2ae841af2525f0db235622315
android_system_image used GatherPackagingSpecs and then filter only
system modules. But some modules were omitted in this logic because
there are modules which has the same relative path, so the later one is
ignored even though its partition info is what we're looking for. So add
filter logic in GatherPackagingSpecs to avoid this problem
Bug: 323793487
Test: build android_system_image, and then check if it contains every
module we want
Change-Id: Iec8ae920736d3d1920eecad71ba0f8f2fe848e6c
Convert coverageMutator to a TransitionMutator as a step towards
variants-on-demand.
Bug: 319288033
Test: coverage_test.go
Test: treehugger coverage builds
Change-Id: Ic50c0040dea8b42c36b5d784221daa00b7b0d379
The --rollback_index value is interpreted as base 10 by default; fix the
avb_add_hash_footer rule to print values in base 10 rather than hex.
This doesn't affect any current build targets since all usages have
rollback_index < 10 at the moment so base 10 and hex are identical.
Test: a rollback_index of 12 failed build previously, now succeeds
Change-Id: Ib6cafacca02f8792a0bf3a1e733fc89ee16adebb
