On Sat, Apr 6, 2019 at 11:48 AM Robert Ramey via Boost <boost@lists.boost.org> wrote:
OK so the complete answer to the poster's question would be:
a) build you're own instance of boost libraries - at least the ones that you use.
b) with options that you need and the name/root you want do use.
c) and test those builds with the tests provide for each library
d) and report any problems.
Is the information easily available in the Boost Build documentation to do this? I think it should be. In fact I think every time a question like this comes it, the boost library and tool maintainers should add a section to the the boost build documentation: Example ... or Case Study ... . Since the same questions tend to be posted again and again, eventually the need to make such additions to the manual will will taper off. At that point all these kinds of questions can be answered with a simple "see example ... in the documentation (you lazy moron). So, though my suggestion seems like it would be creating more work, it's actually an investment of effort designed to diminish total amount of work required to support the tool.
Robert Ramey
Hi Robert, I get what you're saying, and we don't mind to build our own version. But this issue is not a regular issue, like some minor macros/flag we want to enable to fix some build errors. It is a serious one. And for mitigating it, MSVC team even released a special version of CRT (https://devblogs.microsoft.com/cppblog/spectre-mitigations-in-msvc/). We do have other issues while fitting boost into our build system, but we never reached out for those things. We only reached out for this one, as we believe this is the better way to fix it and can help the entire community. Please help reconsider it again. Also please pardon the delay of my message. Maybe I misused the mail list, somehow all of my messages need to be approved, so it might take some time. Thanks, Riff On Sat, Apr 6, 2019 at 11:55 AM Robert Ramey via Boost <boost@lists.boost.org> wrote:
Forgot to mention: I don't think any kind of important code should be depending on binaries. For this reason, I don't think that Boost should be distributing binaries at all. To me, it's bad practice.
I realize that in some cases it's unavoidable, (libc, etc. zlib, et.all). But still, I should be less preferred option for code which requires any consideration of modern security problems.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost