Better centralize package defaults into PackageArgs Package defaults are currently somewhat haphazardly specified in Package and PackageArgs. Instead, more consistently get package defaults from PackageArgs: * Remove all getDefault??? parameters from Package and Package.Builder. Instead declare getPackageArgs to get the container of all package defaults. * Move defaultHdrsCheck into PackageArgs (was in Package) as it IS a package default being set by the package() function. See NOTE below. * PackageArgs.processParams now uses a select statement for both readability and mild theoretical performance gains. * AttributeMap now just needs to simply declare an abstract getPackageArgs rather than an ever-growing list of getDefault??? Ultimately, this should clarify mutability a bit. The result of Package.getPackageArgs is 'done' and thus should no longer change. In contrast, Package.Builder.getPartialPackageArgs is subject to change as the build file is further processed. NOTE: This does allow Bazel users to specify default_hdrs_check inside of package() (in order to make handling this attribute more consistent with all of the others). As future work: PackageSerializer can almost assuredly be simplified to more clearly and directly serialize/deserialize PackageArgs rather than inline this ser-des process into itself. Remove Package.Builder.getPartialPackageArgs. This is clearly incomplete and the result of these reads depends on the location of package() in the BUILD file. default_hdrs_check likely needs further cleanup to act more consistently with the other attributes. Need to be more consistent on where getPackageArgs is called (in a ComputedDefault attached to an attribute versus transitively in CobinguredTargetFunction via RuleContext lookups). This is likely the underlying culprit for some attributes acting strangely under query. The default_settings portion of the output formatters should likely be removed in favor of something more principled (either just relying on having those attributes be populated via ComputedDefault or dumping all of PackageArgs into default_settings). PiperOrigin-RevId: 544666167 Change-Id: I2251aaf7b4f2d21372eec60d333679cc6d851b7f
{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