`@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>
hchsiao