Specifically:
selects.config_setting_group(
name = "always_true",
match_any = ["//conditions:default"],
)
and
selects.config_setting_group(
name = "always_true",
match_all = ["//conditions:default"],
)
These should, as expected, always evaluate to True.
Their implementation had a bug that failed the build outright.
* Create a helper rule for selecting a file from outputs of another rule or a filegroup by subpath
* Add tests
* Address code review comments
* + formatting
Co-authored-by: c-parsons <cparsons@google.com>
The output directories for the target under test may differ when the target is under a config transition (config_settings is passed to analysistest.make). Since analysis tests may assert about the command-line of generated actions, and those command-lines may contain paths to output files, this is useful information to expose.
* 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.
* Make sets.bzl point to new_sets.bzl instead of old_sets.bzl
new_sets.bzl and old_sets.bzl should be removed in the following skylib release.
Fixes #155.
* update and rename test suites
This rule is an alternative for genrule(): it can
run a binary with the desired arguments,
environment, inputs, and outputs, as a single
build action, without shelling out to Bash.
Fixes https://github.com/bazelbuild/bazel-skylib/issues/149
native_binary() wraps a pre-built binary or script
in a *_binary rule interface. Rules like genrule
can tool-depend on it, and it can be executed with
"bazel run". This rule can also augment the binary
with runfiles.
native_test() is similar, but creates a testable
rule instead of a binary rule.
Fixes https://github.com/bazelbuild/bazel-skylib/issues/148
RELNOTES[NEW]: The new `native_binary()` and `native_test()` rules let you wrap a pre-built binary in a binary and test rule respectively.
The user can specify which line endings they want
write_file to use. This helps avoiding line ending
mismatches with diff_test.
Example: diff_test verifies that a rule generates
correct output by comparing it to a checked-in
"golden" file. Both files are text files, and the
user builds on Windows but the golden file was
written on Linux and git checkout preserved
original line endings.
Without explicitly specifying which line endings
to use, this diff_test would fail on an otherwise
good output.
With explicit line endings we don't need to check
in the golden file to git, we can just generate it
with "auto" line endings.
* Fix a number of misc issues to allow google usage of bazel-skylib
1. Missing copyright header
2. Shell test fixes to use TEST_TMPDIR to have write access to directories
3. diff_test fix to use TEST_SRCDIR
* added a comment as to why diff_test_tests is local
* ran buildifier
This new test rule compares two files and passes
if the files match.
On Linux/macOS/non-Windows, the test compares
files using 'diff'.
On Windows, the test compares files using
'fc.exe'. This utility is available on all Windows
versions I tried (Windows 2008 Server, Windows
2016 Datacenter Core).
See https://github.com/bazelbuild/bazel/issues/5508
See https://github.com/bazelbuild/bazel/issues/4319
Fixes some dictionaries to put things in the more common orders. Buildifer
used to default to doing this check and reformatting which is why the
//conditions:default got moved up in these in the first place.
All tests work with
`--incompatible_windows_native_test_wrapper`
except for the ones already broken on Windows
(//tests:analysis_test_e2e_test and
//tests:unittest_e2e_test).
See https://github.com/bazelbuild/bazel/issues/6622
Move maprule() to a private directory, to
discourage use of it. I (@laszlocsomor) am
planning breaking changes to it.
Also move private files (rule implementations) to
a subdirectory "rules/private/", to clean up the
"rules/" directory.
This PR adds two new rules: write_file and
write_xfile.
Both rules solve a common problem: to write a text
file with user-defined contents.
The problem is routinely solved using a genrule.
That however requires Bash, since genrules execute
Bash commands. Requiring Bash is a problem on
Windows.
The new rules do not require any shell.
The only difference between the rules is that
write_xfile creates an executable file while
write_file doesn't.
See https://github.com/bazelbuild/bazel/issues/4319
This PR adds two new rules: copy_file and
copy_xfile.
Both rules solve a common problem: to copy one
file to another location. The problem is routinely
solved using a genrule. That however requires
Bash, since genrules execute Bash commands.
Requiring Bash is a problem on Windows.
The new rules do not require Bash on Windows (only
on other platforms).
The only difference between the rules is that
copy_xfile creates an executable file while
copy_file doesn't.
See https://github.com/bazelbuild/bazel/issues/4319
In this PR:
- In the _resolve_locations function: use the
Bash-less ctx.resolve_tools function to resolve
the runfiles manifests and inputs of tools,
instead of using ctx.resolve_command for
the same purpose.
- In the _custom_envmap function: no longer
resolve $(location) references when
creating the envvars from custom_env, because
those references were already resolved in
_resolve_locations.
The ctx.resolve_tools() method was added in this
PR: https://github.com/bazelbuild/bazel/pull/7139
See design doc there.
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.
Greg