From: David Abrahams (dave_at_[hidden])
Date: 2005-03-21 16:21:20
"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:
> I would like to reiterate my concern about wave tool/library. I did not want
> to continue original discussion, cause I did not want to interfere with the
> review (I actually believe wave is a valuable tool that needed to be
> accepted). In following items I will try to justify my position that it
> (wave tool/library) needs to be treated as a tool not a library:
> I. It doesn't really fit into our library review model
> 1. Any review period wouldn't be enough for the majority of reviewer to
> get any (if any) decent look on implementation. Not only because it quite
> big, but because it require special knowledge
> 2. To be able to give any opinion on the design, one need essentially
> detail knowledge of C++ specification in regards to preprocessor. And I
> couldn't see how reviewer could see how design meet the requirements within
> review period.
> 3. Reviewers couldn't run test to check this tool do what it supposed
> to do.
> II. It has different target audience then boost libs
> I believe that in 99.99% of use cases it is going to be used as a tool, not
> as a library. One could probably need custom C++ preprocessor, but only in
> academic purposes, and definitely not in production.
> III. It doesn't really fit a maintenance model
> I don't see that any tester will ever run regression tests for the
> wave. And definitely not on regular basic as we do with rest of
> boost libs.
> IV. It doesn't really fit distribution model
> We distribute our libraries in a form of source code.
We also distribute our tools that way. We have pre-built binaries of
bjam for a few select platforms, but that's just a convenience. I
don't believe bcp, regression, et. al are distributed as binaries.
> It doesn't seems reasonable for wave. It should be distributed in a
> binary form. As I said majority of it's target audience will use it
> as a tool and shouldn't be punished if they use a compiler that
> couldn't handle spirit for example.
What kind of punishment do you envision?
> On the other hand we are adding meg of source code that nobody
> (almost) will ever look into (other then spend time to compile a
> tool). Also documentation for this tool should be really tool-user
> directed - no need for the implementation to blur the view unless
> one is interested in it.
> I believe we need to introduce formal division on tools and libraries within
> boost. We already have couple useful tools that my have usage outside of
> boost (we need to document the first), I see several others that could be
> added. The review procedure for the tools should be different from the
> libraries. Essentially we need to review only the users guides and run
> already rebuilt executables.
If tool portability matters (and it often does), it seems to me
testing the build may be important.
> There may be something else I missing, we should discuss it.
> I believe there is a reason why language working group is separate from
> library working group in standardization committee.
How do those reasons apply to us?
> Let's keep clear
> separation of concepts here also.
I'm not neccessarily opposed to what you're advocating, but so far you
haven't made a clear case that it will have benefits, or that doing
otherwise will have a cost. Could you boil the pros/cons down to a
bullet list or something?
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk