[boost] Re: [wave] tool/lib

From: David Abrahams (dave_at_[hidden])
Date: 2005-03-21 16:21:20

"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:

> Hi,
>
> 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.

Why not?

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

Why not?

> 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