Keith Smiley
Keith Smiley
It's possible that users don't have a `bazel` in their path depending on your project configuration. This allows passing `--bazel whatever` to override to a custom wrapper, or anything else.
This fix existing as a symlink to a cmake directory seems like a pretty common use case, and the error when it fails to write is pretty inscrutable. Fixes https://github.com/hedronvision/bazel-compile-commands-extractor/issues/105
This modernizes the bazel setup to support 7.x, still using the WORKSPACE
As far as I can tell all the uses of http_file in the MODULE.bazel are dev dependencies, therefore they're easy to move to the WORKSPACE.bzlmod to avoid using the bazel...
This didn't vary per platform so we don't need N of them
This is the same as 27.0 but with https://github.com/protocolbuffers/protobuf/pull/16884 to make java targets work for grpc-java and others.
Since this target has no srcs these are unused
The toolchain was passing -l:name. This mechanism doesn' t exist on macOS, instead the full path to the shared library should be passed. This is a cherry pick of f0ade80ce920be0719b1a43a40258397f68a944d...