3. Reviewers couldn't run test to check this tool do what it
supposed
to do.
Why not?
1. Because from what I understand one need quite expensive test harness for that. 2. It require quite a lot of time and resources.
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?
See above
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?
I want to use wave preprocessor instead of compiler supplied because it's buggy, nonconformant e.t.c. but couldn't do so because I couldn't compile one with my compiler for the same reasons.
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?
I thought it should be clear: imagine if all C++ issues both core language and STL development would be discussed in a single big group. They are separated because they represent different domains. Libraries and tools are also separate domains with different requirements for portability, clarity, flexibility. Tools for us more like black box - we don't need to know how they do their work. While with libraries we interested how they do, whatever they do. Libraries directed for the end user to compile with. Tools on the other hand are to be executed.
Let's keep clear separation of concepts here also.
I'm not necessarily 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?
Ok. Let's see what are pros/cons in treating wave (and any other tool) as a separate notion: PROS No need to deliver source code or it could be separate package - in case of big tool in could be significant savings in delivery package size End user do not need to compile it End user could use it even if doesn't have a compiler that is able to compile one We don't need to spent time in /resolve issues with regression testing, which in many cases is either impossible and/or very time consuming Tool author do not need to spend time writing reference and any other documentation that covers internals Tool author do not really need to follow all boost guidelines to insure code quality - eventually this will speed up time before tool appear Review is simplified - actually tools reviews could be in separate queue and run concurrently with libs reviews CONS Users interested in using tool as a library will need to download an extra package Tool author may need to prepare two version of docs - one for end user and one for lib user Some extra initial work to introduce this notions separation from both organization and implementation stand point We kinda moving in nearby areas in software development space (libraries vs. tools that help write libraries). But this is OK IMO. I may've missed something Regards, Gennadiy