Targets of this rule verify that targets can be analyzed successfully.
This is similar to build_test, except no actual action execution of
the underlying targets occur. analysis_test essentially verifies that
`bazel build [targets] --nobuild` passes.
maprule() is an improved version of
native.genrule(), with the following advantages:
- Maprule can process source files in parallel,
creating separate actions for each of them.
- Maprule does not require declaring all output
files. Instead you declare templates for the
output files yielded for each source. Therefore
N source files and M templates yield N*M
outputs.
- Maprule supports both Bash and cmd.exe syntax
for its commands via the specialized rules
bash_maprule and cmd_maprule.
- Maprule's cmd attribute does deliberately not
support $(location) expression nor Make
Variables, in order to avoid issues and
challenges with quoting. (In case of cmd.exe
passing empty arguments is impossible). These
paths can be passed as envvars instead.
- Maprule's add_env attribute does support
$(location) expressions (and some extra
placeholders) and is the idiomatic way to pass
execpaths of labels in "tools" or "srcs" (the
shared sources available for all actions) to the
command.
See https://github.com/bazelbuild/bazel/issues/4319
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
Most notably, this renames/moves a few important identifiers:
//:skylark_library.bzl -> //:bzl_library.bzl
skylark_library -> bzl_library
SkylarkLibraryInfo -> StarlarkLibraryInfo
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.
* Skylint: Move comment out of docstring.
Is skylint seems more than a single like docstring, it expect a full comment
with Args/Returns/etc.; avoid having to have full docstring but just making
the comment a comment and not part of the docstring.
* Address some skylint issues.
- ctx.file_action -> ctx.actions.write
- Return an empty list of providers rather then an old style empty struct.
This version is hash-based (implemented on top of a dictionary) and doesn't suffer the performance problems of the current version. It will eventually replace the old one after a deprecation period.
Christopher Parsons