Keith Smiley
Keith Smiley
The performance impact of using the global module cache is so significant for projects with multiple swift_library targets, and the crashes seem to be so rare, that I think this...
This breaks IDE integrations. I imagine it's a Swift change that we should fix upstream, or workaround in the worker. Related https://github.com/bazelbuild/tulsi/issues/262
In some cases the default `-D` flags are not desirable since users prefer to control them themselves.
There are quite a few features at this point that are useful to different folks. It would be useful for new users to see what is available so they can...
When you have targets like these: ```bzl load("@build_bazel_rules_apple//apple:ios.bzl", "ios_unit_test") load("@build_bazel_rules_swift//swift:swift.bzl", "swift_library") cc_library( name = "cclib", srcs = ["ccfoo.cc"], linkopts = ["-some-flag-that-should-break-linking"], tags = ["swift_module"], ) swift_library( name = "swiftlib", srcs...
If you have a pre-compiled framework vended by `apple_static_framework_import` in the root of your WORKSPACE, if you depend on it from a `swift_library` rule you will get a strange build...
Through the investigation of https://github.com/bazelbuild/bazel/issues/12049 one of the things I discovered was that when using `actions.run` there are 2 options for environment variables. `use_default_shell_env = True` is recommended, but cannot...
This fixes https://github.com/bazelbuild/bazel/issues/12049 and apparently is the recommendation wherever possible.
As brought up here https://github.com/envoyproxy/envoy/pull/18174#pullrequestreview-762466025 it might be worth having some sort of envoy-mobile CI check as a non-blocking step on envoy PRs (potentially opt in only). This would be...