[boost] [wave] tool/lib

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-03-21 14:10:17

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.

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. 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. 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. 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. Let's keep clear
separation of concepts here also.

Regards,

Gennadiy