`@bazel_tools` is tricky since it is effectively a part of the standard
library that can not have a `bzl_library` attached to it. As a simple
fix for this, `bzl_library` can have a srcs dependency on it so that it
includes the transitive closure of all of its dependencies.
`@bazel_tools` imports are rewritten into the `srcs` attribute since
they are `exports_files`ed from the @bazel_tools.
Co-authored-by: c-parsons <cparsons@google.com>
* Move Gazelle extension to //gazelle/bzl and change package name
This fixes an issue with importing bazel-skylib into
google3. Currently, Glaze (internal Go build file generator) attempts
to generate a target (//gazelle:gazelle) that conflicts with one
that's already declared here.
I think the right solution is actually to move the package into a
subdirectory. In the future (bazelbuild/bazel-gazelle#5), Gazelle's Go
extension will generate target names similar to what Glaze does, so
the same conflict will happen in open source. I think it's also
logical to have a directory of packages in case more need to be added
in the future, and for the extension to have a package name matching
the language it works with.
This is an incompatible change, but the //gazelle directory isn't part
of a tagged release yet, so hopefully it won't break anyone.
* fix runfiles access in test
* Fix gazelle package names.
Co-authored-by: Jay Conrod <jayconrod@google.com>
This should fix some buildkite CI flows, ensuring success of
this test is no longer tied to the current compilation_mode.
It also improves the error message of the offending evaluation.
- while the federation code is in flux, this will mean less churn for skylib
- rules_pkg is only needed by developers for making a distribution, so this won't impact users.
- when we develop a new federation model, we can re-depend the right way.
Without this change, evaluating bzl with strict dependencies results in an error.
[`load(":new_sets.bzl", _sets = "sets")`](560d7b2359/lib/sets.bzl (L17)) results in `No such file or directory: 'third_party/bazel_skylib/lib/new_sets.bzl`
* copy_file: Add parameter to allow symlinks
This change adds a new parameter `allow_symlinks` to `copy_file` that
allows the action to create a symlink instead of doing an expensive
copy if the execution platform (host) allows it.
Updates #248
* Update docs
* Refactor `is_executable` into attribute
* Fix typo
* s/_impl/_copy_file_impl/
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
