> but it seemed to me that the complaint was about using BoringSSL at all. From the article: "but it raises the bigger question of why are we compiling BoringS

> but it seemed to me that the complaint was about using BoringSSL at all. From the article: "but it raises the bigger question of why are we compiling BoringSSL in the first place?" (emphasis mine). I think the "compiled" part of that is doing the heavy lifting. > On Rust-land, I've noticed that some libraries like to have a fallback or compile time config flag to use the vendored version, but still provide a way of using the system's version. This is probably a good middle ground, but it might be more harmful than helpful than if it instead just linked to direction for how to install it yourself (at the simplest level it's almost always ./configure; make; make install), because then at least it's obvious what happened and what libs are being used and you can find them (in /usr/local or wherever). > I appreciate when both options are available because I've encountered some C libs that were very difficult to set-up on first run and the vendored version usually works out of the box. Anything that the install process can automate should be easy enough to provide directions and maybe some simple helper scripts for. If it's too complicated for someone to do, how is it able to be done in an automated fashion by a dependent in a way that seems to work for most people? (and if it doesn't work for most people, why even offer it)