"Gennadiy Rozental" <gennadiy.rozental@thomson.com> 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