| Age | Commit message (Collapse) | Author |
|---|
|
|
|
See https://github.com/bazelbuild/bazel-skylib/branches and
https://github.com/bazelbuild/bazel-skylib/issues/281.
|
|
|
|
* Explain criteria for contributing
* Update README.md
* Update README.md
|
|
This pair of rules was removed in 58068fe0cc28d8d5e0115bf0e7d80189628f35db, and the docs removed in 084758ff75463750f6c2476348ed9442e7860275 - the links were forgotten.
|
|
* -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
|
|
|
|
|
|
Signed-off-by: Christian Blichmann <cblichmann@google.com>
|
|
The README is referring to the deprecated git_repository() rule, which
causes in Bazel 0.22.
|
|
|
|
|
|
- Retire the use of travis for testing.
- Update buildkite config:
- Enable buildifier testing (close to what was on travis, and is being improved.)
- Update the config to now test the latests release and the latest green, replacing
the "head" testing on travis.
|
|
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.
|
|
|
|
|
|
we'll run skylib as a postsubmit project and
before every release to ensure we don't break
it.
|
|
|
|
|
|
|
|
`skylark_library` targets aggregate `.bzl` files and their dependencies for unit tests as well as Skydoc generation.
|
|
|
|
|
