| commit | 1473988aa1e9b92c42fcbad4e155f247f1983d13 | [log] [tgz] |
|---|---|---|
| author | Googler <brandjon@google.com> | Thu Oct 06 10:22:52 2022 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Thu Oct 06 10:24:15 2022 -0700 |
| tree | ebe0178d96c1f1799d49def65779426f8a583102 | |
| parent | 26be41a5f4ef2b3812665b36f136d2e44ae12688 [diff] |
package_group: Add "public"/"private" constants, fix "//..." meaning This CL does three things: 1. It adds the special package specifications "public" and "private, guarded behind the flag `--incompatible_package_group_has_public_syntax`. 2. It fixes the behavior of package specification "//..." to mean "all packages in the current repo" rather than "all packages in any repo", guarded behind the flag `--incompatible_fix_package_group_reporoot_syntax`. 3. It fixes the behavior of `bazel query --output=proto` (and `--output=xml`) so that the `packages` attribute is serialized without dropping the leading `//` from package names -- it is now `"//foo/bar/..."` instead of `"foo/bar/..."`. This behavioral change is guarded behind `--incompatible_package_group_includes_double_slash`. The .bzl `visibility()` builtin always acts as if the first two flags are enabled. Work toward #11261. Work toward #16323. Work toward #16355. Work toward #16391. RELNOTES: Added three `package_group`-related flags: `--incompatible_package_group_includes_double_slash` (#16391), `--incompatible_package_group_has_public_syntax` (#16355), and `--incompatible_fix_package_group_reporoot_syntax` (#16323). With these flags, `package_group` can now easily specify "all packages", "no packages", and "all packages in the current repo". In PackageSpecification: - fromString(), fromStringPositive(): rewrote docstring, added bool args for flags, renamed or removed vars for simplicity, added handling of public/private and flag behavior - AllPackagesBeneath(): fixed asStringWithoutRepository() for case of //..., which wasn't likely to arise before. - normalize order of equals(), hashCode(), etc. - AllPackages: change hash, and change str representation to "public" - Add NoPackages, symmetric to AllPackages - NegativePackageSpecification: don't reuse the delegate's hash as our own hash verbatim In PackageGroupTest: - Move `testEverythingSpecificationWorks` to above `testNegativeEverything`, and made it use "public" syntax in place of "//...". - Add test for "private" syntax. - Add test for flag guarding "public"/"private". - Add tests for old and new "//..." behavior. - Add tests that you can't negate "public" or "private". - Add test for illegal combination of flags. - Add assertions for stringification of "public"/"private". Other changes: - Update XmlOutputFormatterTest and ProtoOutputFormatterTest with test cases for the flag. In the latter case, parameterize a helper to allow setting per-test-case flags. - Add test cases to BzlLoadFunctionTest for bzl visibility accepting the list forms `["public"]`/`["private"]`, and for its behavior being unaffected by the new flags. PiperOrigin-RevId: 479347358 Change-Id: I124ca5406bff15615adaa1256e2d7bef69b9d9a5
{Fast, Correct} - Choose two
Build and test software of any size, quickly and reliably.
Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.
One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.
Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.
Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.
Follow our tutorials:
To report a security issue, please email security@bazel.build with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. Our vulnerability management team will respond within 3 working days of your email. If the issue is confirmed as a vulnerability, we will open a Security Advisory. This project follows a 90 day disclosure timeline.
See CONTRIBUTING.md
