Remove referring to repo itself when using own rules. (#257)

This is to avoid creating infinite symlink expansion in the GCB job to
create containers.

The reason why this is happening is because in the our GCB job, we
intentially set the bazel output_base to be the /workspace directory in
order for some file mounting needed by the base-images-docker to work properly.
/workspace is also where the source code of the repo is located on the
GCB. The side effect of that is if we use bazel_toolchains as another
external dependency (by adding @bazel_toolchains prefix in BUILD or
WORKSPACE when loading bazel_toolchains repo's own rules), then an
infinitie symlink expansion would occur:

[start of symlink chain]
/workspace/external/bazel_toolchains
/workspace
[end of symlink chain]

We currently haven't found a way on GCB to avoid setting the output_base
to be /workspace, and still keep the file mounting working. And putting
the source code into /workspace is done by GCB and cannot be changed.
1 file changed
tree: 67b90d150aa783edf93aa22200b218d71db66af1
  1. .bazelci/
  2. bazelrc/
  3. configs/
  4. constraints/
  5. container/
  6. examples/
  7. release/
  8. repositories/
  9. rules/
  10. tests/
  11. third_party/
  12. .gitignore
  13. .travis.yml
  14. AUTHORS
  15. CONTRIBUTING.md
  16. CONTRIBUTORS
  17. LICENSE
  18. README.md
  19. WORKSPACE
README.md
Travis CIBazel CI
Build StatusBuild status

bazel-toolchains

https://github.com/bazelbuild/bazel-toolchains is a repository where Google hosts Bazel toolchain configs. These configs are required to configure Bazel to issue commands that will execute inside a Docker container via a remote execution environment.

These toolchain configs include:

  • C/C++ CROSSTOOL file,
  • BUILD file with toolchain rules, and
  • wrapper scripts.

Release information of toolchain configs can be found at: https://releases.bazel.build/bazel-toolchains.html.

This repository also hosts the skylark rule used to generate toolchain configs.