Re: [boost] Enabling spectre mitigation in boost libraries

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 
his ability.

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 
spread.

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 
about this.

Robert Ramey