Add visibility support
Implementation uploaded for review. Includes unit tests but does not yet handle prebuilts, that will come in a future change once some more general issues with prebuilts and namespaces is resolved. See README.md#Visibility for details of what this does and how to use it. Bug: 112158820 Test: add visibility rules for core library modules, make core-tests Change-Id: I8ec980554398ad6f2d42043ce518f811a35da679
This commit is contained in:
72
README.md
72
README.md
@@ -107,6 +107,30 @@ cc_binary {
|
||||
}
|
||||
```
|
||||
|
||||
### Packages
|
||||
|
||||
The build is organized into packages where each package is a collection of related files and a
|
||||
specification of the dependencies among them in the form of modules.
|
||||
|
||||
A package is defined as a directory containing a file named `Android.bp`, residing beneath the
|
||||
top-level directory in the build and its name is its path relative to the top-level directory. A
|
||||
package includes all files in its directory, plus all subdirectories beneath it, except those which
|
||||
themselves contain an `Android.bp` file.
|
||||
|
||||
The modules in a package's `Android.bp` and included files are part of the module.
|
||||
|
||||
For example, in the following directory tree (where `.../android/` is the top-level Android
|
||||
directory) there are two packages, `my/app`, and the subpackage `my/app/tests`. Note that
|
||||
`my/app/data` is not a package, but a directory belonging to package `my/app`.
|
||||
|
||||
.../android/my/app/Android.bp
|
||||
.../android/my/app/app.cc
|
||||
.../android/my/app/data/input.txt
|
||||
.../android/my/app/tests/Android.bp
|
||||
.../android/my/app/tests/test.cc
|
||||
|
||||
This is based on the Bazel package concept.
|
||||
|
||||
### Name resolution
|
||||
|
||||
Soong provides the ability for modules in different directories to specify
|
||||
@@ -139,6 +163,54 @@ should be a space-separated list of namespaces that Soong export to Make to be
|
||||
built by the `m` command. After we have fully converted from Make to Soong, the
|
||||
details of enabling namespaces could potentially change.
|
||||
|
||||
### Visibility
|
||||
|
||||
The `visibility` property on a module controls whether the module can be
|
||||
used by other packages. Modules are always visible to other modules declared
|
||||
in the same package. This is based on the Bazel visibility mechanism.
|
||||
|
||||
If specified the `visibility` property must contain at least one rule.
|
||||
|
||||
Each rule in the property must be in one of the following forms:
|
||||
* `["//visibility:public"]`: Anyone can use this module.
|
||||
* `["//visibility:private"]`: Only rules in the module's package (not its
|
||||
subpackages) can use this module.
|
||||
* `["//some/package:__pkg__", "//other/package:__pkg__"]`: Only modules in
|
||||
`some/package` and `other/package` (defined in `some/package/*.bp` and
|
||||
`other/package/*.bp`) have access to this module. Note that sub-packages do not
|
||||
have access to the rule; for example, `//some/package/foo:bar` or
|
||||
`//other/package/testing:bla` wouldn't have access. `__pkg__` is a special
|
||||
module and must be used verbatim. It represents all of the modules in the
|
||||
package.
|
||||
* `["//project:__subpackages__", "//other:__subpackages__"]`: Only modules in
|
||||
packages `project` or `other` or in one of their sub-packages have access to
|
||||
this module. For example, `//project:rule`, `//project/library:lib` or
|
||||
`//other/testing/internal:munge` are allowed to depend on this rule (but not
|
||||
`//independent:evil`)
|
||||
* `["//project"]`: This is shorthand for `["//project:__pkg__"]`
|
||||
* `[":__subpackages__"]`: This is shorthand for `["//project:__subpackages__"]`
|
||||
where `//project` is the module's package. e.g. using `[":__subpackages__"]` in
|
||||
`packages/apps/Settings/Android.bp` is equivalent to
|
||||
`//packages/apps/Settings:__subpackages__`.
|
||||
* `["//visibility:legacy_public"]`: The default visibility, behaves as
|
||||
`//visibility:public` for now. It is an error if it is used in a module.
|
||||
|
||||
The visibility rules of `//visibility:public` and `//visibility:private` can
|
||||
not be combined with any other visibility specifications.
|
||||
|
||||
Packages outside `vendor/` cannot make themselves visible to specific packages
|
||||
in `vendor/`, e.g. a module in `libcore` cannot declare that it is visible to
|
||||
say `vendor/google`, instead it must make itself visible to all packages within
|
||||
`vendor/` using `//vendor:__subpackages__`.
|
||||
|
||||
If a module does not specify the `visibility` property the module is
|
||||
`//visibility:legacy_public`. Once the build has been completely switched over to
|
||||
soong it is possible that a global refactoring will be done to change this to
|
||||
`//visibility:private` at which point all modules that do not currently specify
|
||||
a `visibility` property will be updated to have
|
||||
`visibility = [//visibility:legacy_public]` added. It will then be the owner's
|
||||
responsibility to replace that with a more appropriate visibility.
|
||||
|
||||
### Formatter
|
||||
|
||||
Soong includes a canonical formatter for blueprint files, similar to
|
||||
|
Reference in New Issue
Block a user