073ea55fad
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
34 lines
1.3 KiB
Go
34 lines
1.3 KiB
Go
// Copyright 2020 Google Inc. All rights reserved.
|
|
//
|
|
// Licensed under the Apache License, Version 2.0 (the "License")
|
|
// you may not use this file except in compliance with the License.
|
|
// You may obtain a copy of the License at
|
|
//
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
|
//
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
// See the License for the specific language governing permissions and
|
|
// limitations under the License.
|
|
|
|
package android
|
|
|
|
// PackagingSpec abstracts a request to place a built artifact at a certain path in a package.
|
|
// A package can be the traditional <partition>.img, but isn't limited to those. Other examples could
|
|
// be a new filesystem image that is a subset of system.img (e.g. for an Android-like mini OS running
|
|
// on a VM), or a zip archive for some of the host tools.
|
|
type PackagingSpec struct {
|
|
// Path relative to the root of the package
|
|
relPathInPackage string
|
|
|
|
// The path to the built artifact
|
|
srcPath Path
|
|
|
|
// If this is not empty, then relPathInPackage should be a symlink to this target. (Then
|
|
// srcPath is of course ignored.)
|
|
symlinkTarget string
|
|
|
|
// Whether relPathInPackage should be marked as executable or not
|
|
executable bool
|
|
}
|