Envoy: init at 1.3.0 #27629
Envoy: init at 1.3.0 #27629
Conversation
|
/cc @benley, since I figure you might be interested, and I presume you have much more experience with bazel than I. |
| "-O2", | ||
|
|
||
| - # Security hardening on by default. | ||
| - # Conservative choice; -D_FORTIFY_SOURCE=2 may be unsafe in some cases. |
There was a problem hiding this comment.
Yeah. Bazel tries to unset that option somewhere, and then gcc complains loudly.
At the moment I have hardeningDisable = "all" set, but I don't think that's applying (because, IIUC, the bazel is clearing the environment) -- the net effect being that I think our hardening is applying any way.
| # BUILD file from (we could instead just include the contents directly); | ||
| # however, this sets us up to be ready if we (or upstream) decide to split | ||
| # things into multiple bazel repos, instead of one. | ||
| ccTargets = { |
There was a problem hiding this comment.
imho it would be slightly more clear to call this cc_libraries since that is what is generated from it
| name = "protobuf_bzl", | ||
| path = "${protobuf_bzl}", | ||
| # We only want protobuf.bzl, so don't support building out of this repo. | ||
| build_file_content = "", |
There was a problem hiding this comment.
Couldn't you use local_repository instead of new_local_repository here and omit the empty build_file_content attr?
There was a problem hiding this comment.
@benley The theory is, I think, that bazel will parse the BUILD file in that git repo. That comment is originally from the Envoy devs. Whether its really necessary, or just being paranoid, I'm not certain.
There was a problem hiding this comment.
Hrm, ok. It's certainly not harmful the way you have it, I was just wondering.
|
|
||
| # Envoy checks at runtime that the git sha is valid, | ||
| # so we really can't avoid putting some sort of sha here. | ||
| rev = "3afc7712a04907ffd25ed497626639febfe65735"; |
There was a problem hiding this comment.
I presume this is the commit matching the "v${version}" tag ... it would be cool if there were a way to collect this commit sha at build time instead of relying on humans to keep the two in sync.
There was a problem hiding this comment.
Yeah, that part kind of bums me out. I might see if I can patch out the self-destruct code that panics when the SHA doesn't look right, and then we could just use version.
Also, include libcrypto.a and libdecrepit.a.
A beautiful stack trace pretty printer for C++
The LightStep distributed tracing library for C++. See: http://lightstep.com
A fast JSON parser/generator for C++ with both SAX/DOM style API. See: http://rapidjson.org/
L7 proxy and communication bus designed for large modern service oriented architectures. See: https://lyft.github.io/envoy/
Motivation for this change
I'm using Envoy at work.
Things done
nix-shell -p nox --run "nox-review wip"./result/bin/)I don't know if the
libeventbump breaks anything, or possibly causes a mass rebuild.Requisite package updates (and additions) have been split into separate commits.