A common point of confusion I see around `run_binary` is that it's hard coded to only expand `$(location` values which in codebases I work in are otherwise completely eliminated due to it being described as "legacy"
> location: A synonym for either execpath or rootpath, depending on the attribute being expanded. This is legacy pre-Starlark behavior and not recommended unless you really know what it does for a particular rule. See [#2475](https://github.com/bazelbuild/bazel/issues/2475#issuecomment-339318016) for details.
If `execpath` is used instead as the appropriate alternative, the rule does no do any expansion and fails the action. This change adds support for expanding all available patterns whenever they're provided.
Adds a new module `modules` with two helper functions for module
extensions:
* `use_all_repos` makes it easy to return an appropriate
`extension_metadata` from a module extension (if supported) to
indicate that all repositories generated by the extension should be
imported via `use_repo`.
* `as_extension` turns a WORKSPACE macro into a module extension that
uses `use_all_repos` to automate the generation of `use_repo` calls.
Allow `bzl_library` to depend on non-`bzl_library` targets
Notably, `filegroup`. `bzl_library` doesn't actually read anything from the `StarlarkLibraryInfo` provider, and requiring all deps to be other `bzl_library` targets is really painful for anyone loading .bzls from `@bazel_tools` or `@platforms` because those core modules/repos don't want a dependency on Skylib just for access to `bzl_library`.
The medium-term plan will be to move `bzl_library` into `@bazel_tools`; but before then, this can serve as a stop-gap.
Co-authored-by: Alexandre Rostovtsev <arostovtsev@google.com>
All actions which use tool or executable for which is not clear if it comes from a toolchain, must set a `toolchain` parameter ( migration of Automatic Exec Groups).
As we discussed internally, I've modified actions so that it's recognised that tools are not from the toolchain. Hence, there will not be an error which states `Couldn't identify if tools are from implicit dependencies or a toolchain. Please set the toolchain parameter. If you're not using a toolchain, set it to 'None'.`. Hence, no need for the toolchain parameter.
While build settings allow for much cleaner flag and setting definitions
than `--define`, they have the major drawback that rules need to provide
dedicated support for them, which isn't the case for native and most
community-maintained rules.
This change attempts to bridge this gap by optionally exposing the value
of the common build setting types as Make variables to rules that depend
on them via the `toolchains` attribute: If the new `make_variable`
attribute is set, the value of the flag or setting is available as a
Make variable with that.
Consistency with pre-defined Make variables is enforced by limiting the
character set for `make_variable` values to `[A-Z0-9_]`. The new
attribute is also only added to int- and string-valued build settings as
the other types lack a canonical stringification.
Co-authored-by: Xùdōng Yáng <wyverald@gmail.com>
After #400, the gazelle plugin has been cleanly separated out into its own bazel workspace, which will soon finally allow us to mark it stable. But this means:
* we need to change our bazelci config to explicitly build and test it, since `bazel build //...` no longer includes the plugin;
* we need to add proper distribution rules for it;
* we need to update release instructions, since now we will have two distribution tarballs
Google internal linters are flagging skylib 1.3.0 because the stardoc_with_diff_test
macro lack a copyright notice and does not use a `name` parameter.
Creates MODULE.bazel and WORKSPACE.bzlmod files to enable bazel-skylib
to work with the `--experimental_enable_bzlmod` flag.
rules_go has been updated as the previously used version is not
available in the BCR.
stardoc has been updated due to a strange issue with Bzlmod enabled that
caused the `diff_test` and `unittest` docs to be generated without any
contents that was magically fixed upon updating.
bazelbuild/bazel-central-registry#124
Co-authored-by: Alexandre Rostovtsev <arostovtsev@google.com>
Followup to #330: remove the wrapper macro and export the rule directly; the macro
does not serve any useful function. As a side effect, this fixes the inability to
set tags etc., since the macro did not support **kwargs.
I find it more ergonomic to add notes or a description about a test to a `doc` attribute, similar to other rules, vs a comment block above it or in the `impl` function docstring. Hopefully this can improve the readability of test rules.
This is a relatively simple addition to unittest that statically creates rules
that either explicitly fail or not depending on if the test case is valid during
LOADING phase of bazel. The test conditions are evaluated entirely in loading
phase, but if we want an actual test to fail rather than just `fail()` killing
the build, we can use this to assert state and report test failures.
See https://github.com/bazelbuild/bazel-federation/pull/127
In particular, this allows us to use a modern Stardoc release to fix generated md docs.
And we can remove internal_deps.bzl/internal_setup.bzl - it's unnecessary complexity
needed only for deprecated Federation setup.
Matt