For example, if you try to match `*a*` against `ab`, then we check:
```
left = ""
middle = "a"
right = ""
middle in name[len(left):len(name)-len(right)]:
"a" in "ab"[len(""):len(name)-len("")]:
"a" in "ab"[0:-0]
"a" in "" => False
```
The problem here is that negative numbers in python index from the back, but -0 is not a negative number, so it always results in the empty string.
Previously, I was getting the error
`Expected external/_main~toolchains~toolchain_sdk/usr/bin/clang++ to start with one of ["external/_main~toolchains~toolchain_sdk//", "bazel-out/k8-dbg/bin/external/_main~toolchains~toolchain_sdk/"]`
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>
This improves the error in the case your bzl_library does nothing.
Otherwise you end up with something weirder later:
```
BUILD:35:12: in deps attribute of bzl_library rule LABEL: 'DEP' does not produce any bzl_library deps files (expected .bzl)
```
Ideally we could set `allow_empty = False` on `srcs` but currently it's
valid to just have a bzl_library target that aggregates multiple other
libraries in its deps.
Co-authored-by: Ivo List <ilist@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>
Required for Bazel 7 compatibility.
Note that rules_pkg 0.9.1 requires Python 3.6 or newer as the system's Python 3; this means we cannot build //distribution on Ubuntu 16.04 any more (which is fine, since it only affects the skylib developer workflow; users of skylib on Ubuntu 16.04 are not affected). Update CI config accordingly.
Fixes #414
I ran into an issue where I had a `build_test` that was only compatible with a particular platform. I had annotated the target with `target_compatible_with` but continued to get builds on the incompatible platform. This came down to my `bazel test //...` invocation picking up the `{name}_{idx}__deps` targets and building the dependency anyway. This change updates these targets to account for newer common attributes and tags them as manual so they're only built when the user facing test target is built.
In order to flip the flag, all downstream projects should be adapted. However, it is hard to fix them all if there are constant regressions. Adding it to the CI will ensure that once the project can build with incompatible_disallow_empty_glob it can keep building like that.
See: bazelbuild/bazel#15327
* Fix location of MODULE.bazel in distro tarballs.
* Remove invalid paths from WORKSPACE files in distro tarballs
* The resulting tarballs should finally be distributable as 1.4.0 in BCR.
Ivo List