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:
Paul Duffin
2019-03-28 14:10:57 +00:00
parent 02cbe8f1c6
commit 2e61fa6e14
7 changed files with 894 additions and 9 deletions

View File

@@ -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