| commit | bc97abb33eaacfff3c31ba64719817e7a808b20d | [log] [tgz] |
|---|---|---|
| author | Ivo List <ilist@google.com> | Thu Aug 20 19:14:55 2020 +0200 |
| committer | GitHub <noreply@github.com> | Thu Aug 20 13:14:55 2020 -0400 |
| tree | 86f268b047f9298ac8918eff74043afb7eebd93b | |
| parent | 68acaa5d6aa65e89d99ac775b3d895fea91a3bae [diff] |
Move bzl ext (#265) * 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>
Skylib is a standard library that provides functions useful for manipulating collections, file paths, and other features that are useful when writing custom build rules in Bazel.
This library is currently under early development. Be aware that the APIs in these modules may change during this time.
Each of the .bzl files in the lib directory defines a “module”—a struct that contains a set of related functions and/or other symbols that can be loaded as a single unit, for convenience.
Skylib also provides build rules under the rules directory.
WORKSPACE fileSee the WORKSPACE setup section for the current release.
If you want to use lib/unittest.bzl from Skylib versions released in or after December 2018, then you also should add to the WORKSPACE file:
load("@bazel_skylib//:workspace.bzl", "bazel_skylib_workspace") bazel_skylib_workspace()
BUILD and *.bzl filesThen, in the BUILD and/or *.bzl files in your own workspace, you can load the modules (listed below) and access the symbols by dotting into those structs:
load("@bazel_skylib//lib:paths.bzl", "paths") load("@bazel_skylib//lib:shell.bzl", "shell") p = paths.basename("foo.bar") s = shell.quote(p)
new_setsSteps to add a module to Skylib:
Create a new .bzl file in the lib directory.
Write the functions or other symbols (such as constants) in that file, defining them privately (prefixed by an underscore).
Create the exported module struct, mapping the public names of the symbols to their implementations. For example, if your module was named things and had a function named manipulate, your things.bzl file would look like this:
def _manipulate(): ... things = struct( manipulate=_manipulate, )
Add unit tests for your module in the tests directory.
bzl_libraryThe bzl_library.bzl rule can be used to aggregate a set of Starlark files and its dependencies for use in test targets and documentation generation.
If you try to use unittest and you get the following error:
ERROR: While resolving toolchains for target //foo:bar: no matching toolchains found for types @bazel_skylib//toolchains:toolchain_type ERROR: Analysis of target '//foo:bar' failed; build aborted: no matching toolchains found for types @bazel_skylib//toolchains:toolchain_type
then you probably forgot to load and call bazel_skylib_workspace() in your WORKSPACE file.