[boost] Re: [wave] tool/lib

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

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