Subject: Re: [boost] Enabling spectre mitigation in boost libraries
From: Robert Ramey (ramey_at_[hidden])
Date: 2019-04-07 04:23:28
On 4/6/19 7:22 PM, Rene Rivera via Boost wrote:
> These are not options pertaining to B2 itself. And hence have no mention in
> the B2 documentation. You can see the options by doing:
> $ cd boost-root
> $ b2 --help
> There are numerous install and build directory options listed in that. Use
> the appropriate one. For the tagging there's a concept of "buildid" for
> which there are two options present. The appropriate place to document
> these in addition to the "--help" printout would be in the Getting Started
> Boost pagesOr perhaps some other "Building Boost" documentation. Or
> optionally the wiki. And it would seem that such "Case Study" examples
> would lend themselves well to having on the wiki. Especially since it's
> really, really, really, easy for everyone to contribute such documentation
> through direct edit suggestion PRs to the wiki.
I think this view is very typical of library and tool developers. And I
think it's a big problem.
a) Technically you're correct in that all the required information is
available if one is willing to dig deep enough and invest some time. I
think the time required is more than you think it is though.
b) You frame task is building the software and the job of "spoon
feeding" the user as beyond the developers responsability and perhaps
c) I think you're dead wrong on this. Your task, should you choose to
accept it, is to create something that lots of people will use and will
d) So, if the task isn't accomplished, the developer isn't done. He's
failed to complete the required task.
e) So this means putting the document on par with the code. The code
programs the machine, and the document programs the user. If one
doesn't work - nothing works.
f) Defining the task in this way and approaching it accordingly will
result in a work flow which shuttles bank and forth between code and
document resulting in better and simpler versions of both. This is
because when problems are discovered, we can fix it in the simplest
place to fix it.
I know you guys are tired of me preaching this repeatedly. I'm sorry
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk