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>
* make the tarball 555
* Split the bins out from the rest of the package and combine the
packages.
This solution is horrible. The better solution is
- We need something like pkgfilegroup in rules_pkg, so we can specify
exectuable mode next to the file.
- But we do not want rules_pkg to appear in the rules/BUILD file
because that would make a runtime dependency.
So we need to
- rewrite rules/BUILD when going into the package.
- or provide magic mapping of files names to mode bits
- or something entirely different.
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.
* -Update changelog to get ready for release 1.0
-Change README to point to releases page for WORKSPACE setup. Otherwise
the readme shipped in the archive can never be in sync with the readme
that has the correct sha256.
* update incompatible changes
* -Update changelog to get ready for release 1.0
-Change README to point to releases page for WORKSPACE setup. Otherwise
the readme shipped in the archive can never be in sync with the readme
that has the correct sha256.
* fix wording of changelog
* remove false file
* 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.
* add empty CHANGELOG.md to try to reuse bazel release.sh
* checkpoint a new distribution method
* Update CHANGELOG.
* checkpoint relnew
* get the tarball working
* fix visibilyt
* whitespace
* punctuation typos
* buildify
* linty fresh
* Comply with the standards of the Bazel federation
This commit allows bazel_skylib to be a member of the Bazel federation, since it adds the required bzl files related to setup and dependencies.
Moreover, it also changes the WORKSPACE to fetch all dependencies through the federation.
* Add copyright and docstring to bzl files
- Update to newer version of stardoc.
- Make lib/selects.bzl stardoc compatible. There must be a block description before Args:
Docs now generate with
bazel build --incompatible_remap_main_repo docs:*
See https://github.com/bazelbuild/bazel/issues/7130 for reasons.
* 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.
Laurent Le Brun