2020-06-02 01:45:49 +08:00
|
|
|
bootstrap_go_package {
|
|
|
|
|
name: "soong-android",
|
|
|
|
|
pkgPath: "android/soong/android",
|
|
|
|
|
deps: [
|
|
|
|
|
"blueprint",
|
|
|
|
|
"blueprint-bootstrap",
|
2020-11-13 00:29:30 +08:00
|
|
|
"sbox_proto",
|
2020-06-02 01:45:49 +08:00
|
|
|
"soong",
|
|
|
|
|
"soong-android-soongconfig",
|
2020-11-19 18:38:02 +08:00
|
|
|
"soong-bazel",
|
2020-06-02 01:45:49 +08:00
|
|
|
"soong-env",
|
|
|
|
|
"soong-shared",
|
|
|
|
|
"soong-ui-metrics_proto",
|
|
|
|
|
],
|
|
|
|
|
srcs: [
|
|
|
|
|
"androidmk.go",
|
|
|
|
|
"apex.go",
|
|
|
|
|
"api_levels.go",
|
|
|
|
|
"arch.go",
|
2020-11-17 07:08:19 +08:00
|
|
|
"arch_list.go",
|
2020-09-29 14:23:17 +08:00
|
|
|
"bazel_handler.go",
|
2020-06-02 01:45:49 +08:00
|
|
|
"config.go",
|
|
|
|
|
"csuite_config.go",
|
|
|
|
|
"defaults.go",
|
|
|
|
|
"defs.go",
|
2020-07-15 06:02:16 +08:00
|
|
|
"depset.go",
|
2020-11-11 10:12:15 +08:00
|
|
|
"deptag.go",
|
2020-06-02 01:45:49 +08:00
|
|
|
"expand.go",
|
|
|
|
|
"filegroup.go",
|
|
|
|
|
"hooks.go",
|
|
|
|
|
"image.go",
|
2020-07-28 03:59:58 +08:00
|
|
|
"makefile_goal.go",
|
2020-06-02 01:45:49 +08:00
|
|
|
"makevars.go",
|
|
|
|
|
"metrics.go",
|
|
|
|
|
"module.go",
|
|
|
|
|
"mutator.go",
|
|
|
|
|
"namespace.go",
|
|
|
|
|
"neverallow.go",
|
2020-10-30 09:23:58 +08:00
|
|
|
"ninja_deps.go",
|
2020-06-02 01:45:49 +08:00
|
|
|
"notices.go",
|
|
|
|
|
"onceper.go",
|
|
|
|
|
"override_module.go",
|
|
|
|
|
"package.go",
|
|
|
|
|
"package_ctx.go",
|
add PackagingSpec
Currently, installation of a module is defined as an action of copying
the built artifact of the module to an install path like out/soong/host
(for host modules) and out/target/product/<device>/<partition> (for
device modules). After the modules are installed, the installed files
are further processed to create packages like system.img, vendor.img,
cvd-host-package.tar.gz, etc.
This notion of installation seems to have originated from the old time
when system.img is the primary product of the entire build process
(modulo a few more like root.img). Packaging the installed files as the
filesystem image was considered as a post-build step then.
However, this model doesn't seem to fit well to the current and future
environment where we have a lot more filesystem images (system, vendor,
system_ext, product, ...). The filesystem images themselves are even
grouped together to form a higher-level filesystem image like super.img.
Furthermore, things like cvd-host-package.tar.gz requires us to be able
to group some of the host tools in a format that isn't filesystem image.
Lastly, we are expected to have more filesystem images that are subsets
of system.img (and their friends) for the Android-like mini OS that will
be running on on-device virtual machines. These all imply that the
packaging (which we call installation today) is not a global post-build
step, but a part of the build rules for creating the package-like
modules.
A model better fits to the new sitatuation might be this; a module
specifies its built artifact and the path where it should be placed. The
latter path is not rooted at out/. It's a relative path to the root
directory which will be determined by another module that implements the
packaging. For example, cc_library will have ./lib (or ./lib64), not
out/target/product/<device>/<partition>/lib as the path. Then packages
like system.img, cvd-host-package.tar.gz, etc. are explicitly modeled as
modules and they have deps to other modules. Then the modules are placed
at the relative path under the package root, and the entire root
directory finally is packaged as the output file (be it img, tar.gz, or
whatever).
PackagingSpec is the first step to implement the new model. It abstracts
a request to place a built artifact at a certain path in a package. It
has extra information about whether the path should be a symlink or not,
and whether the path is for an executable. It currently is created when
InstallFiles (and its friends) are called, and can be retrieved via
the new method PackagingSpecs().
In this CL, no one is using PackagingSpec. The installation is still
done by the existing rules created in InstallFiles, etc. and the
structs are not used for the filesystem images like system.img.
Bug: 159685774
Bug: 172414391
Test: m
Change-Id: Ie1dec72d1ac14382fc3b74e5c850472e9320d6a3
2020-11-09 13:08:34 +08:00
|
|
|
"packaging.go",
|
2020-06-02 01:45:49 +08:00
|
|
|
"path_properties.go",
|
|
|
|
|
"paths.go",
|
2020-06-05 04:25:17 +08:00
|
|
|
"phony.go",
|
2020-06-02 01:45:49 +08:00
|
|
|
"prebuilt.go",
|
2020-07-17 08:49:05 +08:00
|
|
|
"prebuilt_build_tool.go",
|
2020-06-02 01:45:49 +08:00
|
|
|
"proto.go",
|
2020-11-05 20:42:11 +08:00
|
|
|
"queryview.go",
|
2020-06-02 01:45:49 +08:00
|
|
|
"register.go",
|
|
|
|
|
"rule_builder.go",
|
|
|
|
|
"sandbox.go",
|
|
|
|
|
"sdk.go",
|
|
|
|
|
"singleton.go",
|
|
|
|
|
"soong_config_modules.go",
|
2020-01-30 12:07:03 +08:00
|
|
|
"test_suites.go",
|
2020-06-02 01:45:49 +08:00
|
|
|
"testing.go",
|
|
|
|
|
"util.go",
|
|
|
|
|
"variable.go",
|
|
|
|
|
"visibility.go",
|
|
|
|
|
"writedocs.go",
|
|
|
|
|
|
|
|
|
|
// Lock down environment access last
|
|
|
|
|
"env.go",
|
|
|
|
|
],
|
|
|
|
|
testSrcs: [
|
|
|
|
|
"android_test.go",
|
|
|
|
|
"androidmk_test.go",
|
2020-10-03 01:26:04 +08:00
|
|
|
"apex_test.go",
|
2020-06-02 01:45:49 +08:00
|
|
|
"arch_test.go",
|
|
|
|
|
"config_test.go",
|
|
|
|
|
"csuite_config_test.go",
|
2020-07-15 06:02:16 +08:00
|
|
|
"depset_test.go",
|
2020-11-11 10:12:15 +08:00
|
|
|
"deptag_test.go",
|
2020-06-02 01:45:49 +08:00
|
|
|
"expand_test.go",
|
|
|
|
|
"module_test.go",
|
|
|
|
|
"mutator_test.go",
|
|
|
|
|
"namespace_test.go",
|
|
|
|
|
"neverallow_test.go",
|
2020-10-30 09:23:58 +08:00
|
|
|
"ninja_deps_test.go",
|
2020-06-02 01:45:49 +08:00
|
|
|
"onceper_test.go",
|
|
|
|
|
"package_test.go",
|
2020-11-09 17:38:48 +08:00
|
|
|
"packaging_test.go",
|
2020-06-02 01:45:49 +08:00
|
|
|
"path_properties_test.go",
|
|
|
|
|
"paths_test.go",
|
|
|
|
|
"prebuilt_test.go",
|
|
|
|
|
"rule_builder_test.go",
|
|
|
|
|
"soong_config_modules_test.go",
|
|
|
|
|
"util_test.go",
|
|
|
|
|
"variable_test.go",
|
|
|
|
|
"visibility_test.go",
|
|
|
|
|
],
|
|
|
|
|
}
|