Re: [boost] Factoring out Test Library wrapstrstream

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-11-27 09:29:10

----- Original Message -----
From: "Rozental, Gennadiy" <gennadiy.rozental_at_[hidden]>
To: "'Boost mailing list'" <boost_at_[hidden]>
Sent: Tuesday, November 26, 2002 7:13 PM
Subject: RE: [boost] Factoring out Test Library wrapstrstream

> > (3) fully included
> > The problem with this is that I put the burden of doing so to
> > the user.
>
> I do not get it. In this case you are the user (of Boost.Test library). To
> use fully included version you are using
>
> #include <boost/test/included/test_exec_monitor.hpp>
>
All right... I totally missed this...
I thought 'fully included' meant something else. Sorry.
(btw: I couldn't find this on the Docs... perhaps it's just me)

NOTE:
I tried to use this method with the numeric library test.
Using bcc55, I encountered the following error on "test_tools.cpp":
__strcmp__ is not a member of std

I had to add the following to that source file, right before the opening
namespace boost:

# ifdef __BORLANDC__
#pragma intrinsic -strcmp
# endif

> And that's it. No need for linking.
>
> > I could use jamfiles, but jam builds doesn't work on every supported
> > platform.
> > For instance, it doesn't work on mine (borland), so I can't resort to
> > jamfiles to attach the test framework to a simple test with a
> > single file.
>
> Works for me.  On windows I am testing using MSVC, GCC and BCC.
> Look on Boost.Test unit tests Jamfile.
>
I know there are Jamfiles for bcc, but I can't get them to work.
The problem is not with the compilers but with bjam on cygwin on Win98
On this platform, bjam produces command lines longer than the shell limit so
the compiler gets its input trimmed off.

Did you effectively used bjam on your computer to actually build the Test
Framework with those windows compilers? What platform are you using for
this?

> > (2) fully linked
> > Similarly, this requires me (and eventually the end user) to
> > compile the
> > test framwwork with every platform I want to test against.
> > This is a burden
> > in some cases. For example, since Borland doesn't work with
> > bjam, I need to
> > do it by hand for this compiler. Similarly, I need to go
> > through all the
> > trouble of building the test framework with every compiler I
> > want to test my
> > code against. This is too much for a single file test which
> > would use just a
> > small subset of the Test Framework
>
> AFAIK Boost.Test is compiled and works for all supported
> compilers/platforms. With and without Jamfile.
>
I know that it *can be* compiled on all supported platforms. But I wouldn't
say that it *is* compiled.. it isn't on my computer...:-)   I need to
compile it manually.
Perhaps these could be solved if you upload to the files sections the
binaries for the supported platforms.

> > Great.
> > If I'm not mistaken, most of the stuff from test_tools.hpp
> > can be rearranged
> > so that it becomes self-contained.
> > That is, it would be possible to use some of it by simply including
> > test_tools.hpp, with possibly a macro switch to indicate that its
> > definitions shall be included right into the translation unit being
> > compiled.
>
> No. Majority of the staff in test_tools.hpp depends on unit_test_log,
> unit_test_results and on test_tools.cpp of course. Those three modules
> constitute the 80 percent of unit test framework and separating them would
> not buy you to much.
>
I see.

> > Even if you rearrange test-tools so that it can be used
> > standalone without
> > external modules that needs to be linked or added to the
> > project, I think
> > that wrapstrstream() would be quite useful on its own. Using
> > a text stream
> > to quickly format text on the fly is a very common operation, and
> > wrapstrstream() provides a nice solution for it.
> >
>
> All right. I will try to prepare standalone file + doc for submission. Do
we
> need the review for this?
>
I don't think we should need a review for this.

Fernando Cacciola