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.
* Add sets.is_set() to test whether an arbitrary object is a set.
Since using sets requires special API, it can be useful to determine
whether an object is a set so special handling can be used.
For example, if a method wants to be able to take a list or a set.
In this commit:
- change unittest.bzl to declare a named output
file instead of relying on the deprecated [1]
default output name (ctx.outputs.executable).
- define a new toolchain_type and toolchain rules
for cmd.exe and for Bash (basically Windows and
non-Windows)
- register the new toolchains in workspace.bzl
- let unittest.make-created test rules require the
new toolchain_type
- write the test output script as a Windows batch
script or as a Shell script, depending on the
selected toolchain
This PR enables the Bazel team to break the Bash
dependency (for test execution) on Windows, and
can run Starlark unittests with the new,
Windows-native test wrapper (still under
development).
See https://github.com/bazelbuild/bazel/issues/5508
As more things are added, lib.bzl is an anti-pattern as the cost of loading
it actually just keeps increasing and most things will never use everything
out of it. The pattern the should be used is to directly import the modules
one uses.
Buildifier 0.12.0 includes initial support for reformatting .bzl files.
- Reformat all the bzl files.
- Expand the travis check to check the .bzl files also.
Even though it's not great to use type checks, they are frequently useful for
checking input types of macros.
Because there is no standard way of checking types, at least 2 types of checks
are used:
- `type(foo) == type([])`
- `type(foo) == "list"`
The first option is not very readable and the second option seem to be relying
on an Bazel implementation detail. Encapsulating type checks into this library
enables consistent and easy to understand type checking without explicitly
relying on implementation details.
kotlaja