external/bazel-skylib.git - [no description]

Age	Commit message (Collapse)	Author
2020-10-21	Handle "internal" directory visibility (#274)	Andrew Z Allen
	Both "internal" and "private" directories should be treated the same way and have visibility restrictions be placed upon them.
2020-10-19	Gazelle now handles imports from `@bazel_tools` (#273)	Andrew Z Allen
	`@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>
2020-09-07	Add support for gazelle handling relative imports (#271)	Samuel Giddins

2020-08-20	Move bzl ext (#265)	Ivo List
	* 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>
2020-06-26	Create Gazelle language for Starlark (#251)	Andrew Z Allen