cppunit-devel — CppUnit Developer Mailing List

Re: [Cppunit-devel] 2. configure.in queries

[Steve M. R. <ste...@vi...>]

On Fri, Jul 06, 2001 at 01:53:55PM +0200, Bastiaan Bakker wrote:

> > Would anyone object to the following two changes to configure.in?
> > 
> > 1. remove AM_DISABLE_STATIC

  [ ... ]
> Let's remove it and see what happens :-)

OK, I'll do so when sourceforge comes back to life.


> > 2. bump the version string to 1.5.6
> > 
> > Rationale: to differentiate CVS cppunit from the last released
> > version.  
> 
> But then how do you differentiate between CVS and the upcoming 1.5.6? 
> Basically we have 2 choices: 
> 1) update the version number immediately before a public release.
> 2) update the version number immediately after a public release.

There is a third option: do both.  That's how you can distinguish
between public releases and CVS.  

 
> 1) is what we (I) do now, and it is also the method described in the
> autoconf/automake docs.

I didn't realise this was discussed in the autoconf/automake docs.
I typically follow a procedure something like that described in libtool's
"README-alpha" (see below) which I now see uses option #3, in fact.

 
> So let's update to version 1.5.6, and work towards a release of it. Then
> immediately update the version 1.5.7 and maybe straight to 1.6.0 if the
> feature set changes to much.
> 
> Does anyone have showstopper issues for a 1.5.6 release? 

I implemented a workaround last night for systems that lack <sstream>,
based on your suggestion of some weeks ago.  I'd like to commit that
before the next release.

Incidentally, I noticed that the generic "INSTALL" file has changed
with autoconf 2.50.  Since the latter is now mandatory, I'll update
the INSTALL in CVS, too.


-Steve




------------ Excerpt from README-alpha in libtool CVS ------------------

================================================================
= Administrivia

* If you incorporate a change from somebody on the net:
  If it is a large change, you must make sure they have signed the
  appropriate paperwork, and be sure to add their name and email
  address to THANKS

* If a change fixes a test, mention the test in the ChangeLog entry.

* If somebody reports a new bug, mention his name in the ChangeLog entry
  and in the test case you write.

* The correct response to most actual bugs is to write a new test case
  which demonstrates the bug.  Then fix the bug, re-run the test suite,
  and check everything in.

* Some files in the libtool package are not owned by libtool.  These
  files should never be edited here.  These files are COPYING, INSTALL,
  config.guess, config.sub, install-sh, mdate-sh, mkinstalldirs,
  texinfo.tex.

* Changes other than bug fixes must be mentioned in NEWS

================================================================
= Test suite

* Use "make check" liberally, on as many platforms as you can.  Use as
  many compilers and linkers you can.


================================================================
= Release procedure

* Fetch new versions of the files that are maintained by the FSF.
  config.guess and config.sub are available via ftp from
  ftp://ftp.gnu.org/gnu/config/

* Update NEWS.

* Update the version number in configure.in.
  (The idea is that every other alpha number will be a net release.
  The repository will always have its own "odd" number so we can easily
  distinguish net and repo versions.)

* Configure, build, and install.

* Commit

* Run `make cvs-dist' which will tag the tree with release-maj-min<alpha>.

* Run `make cvs-diff' which will create a diff file against the previous
  release tag (set OLDVERSION=min.maj<alpha> in the environment beforehand
  if necessary).

* Download a copy of the previous release tarball and generate an
  xdelta with:

    xdelta delta libtool-<prev>.tar.gz libtool-<version>.tar.gz > \
    libtool-<prev>-<version>.tar.xdp.gz'

* Upload release tarball, diff file and xdelta file 
  ftp://melange.gnu.org/~ftp/gnu/libtool and send announcement to
  li...@gn....

* If not an alpha, announcement must also go to inf...@gn..., and an
  upload request be sent to ftp...@gn... requesting files be transferred
  from ftp://alpha.gnu.org/gnu/libtool to ftp://ftp.gnu.org/gnu/libtool.

* Update version number in configure.in to next alpha number.

* Commit.

--------------------------------------------------------------------------

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

RE: [Cppunit-devel] 2. configure.in queries

[Bastiaan B. <bas...@li...>]

> -----Oorspronkelijk bericht-----
> Van: Steve M. Robbins [mailto:ste...@vi...]
> Verzonden: Friday, July 06, 2001 3:54 AM
> Aan: CppUnit Development
> Onderwerp: [Cppunit-devel] 2. configure.in queries
> 
> 
> Would anyone object to the following two changes to configure.in?
> 
> 1. remove AM_DISABLE_STATIC
> 
> Rationale: libtool-based packages typically build both shared and
> static libs by default (configure has --disable-static &
> --disable-shared flags for the installer to customize to her taste).
> The principle of "least surprise" dictates that we stick to that
> unless there is a compelling reason for NOT building static
> libcppunit.a.  Is there such a reason?
> 

Not that I know of. Let's remove it and see what happens :-)

> 2. bump the version string to 1.5.6
> 
> Rationale: to differentiate CVS cppunit from the last released
> version.  

But then how do you differentiate between CVS and the upcoming 1.5.6? 
Basically we have 2 choices: 
1) update the version number immediately before a public release.
2) update the version number immediately after a public release.

1) is what we (I) do now, and it is also the method described in the
autoconf/automake docs.

However 2) makes more sense when your project has a main branch for
development and release branches for bug fixes. So far we have not needed to
branch yet, but when we do need to we'll have to adopt this approach anyway.
So let's update to version 1.5.6, and work towards a release of it. Then
immediately update the version 1.5.7 and maybe straight to 1.6.0 if the
feature set changes to much.

Does anyone have showstopper issues for a 1.5.6 release? 

Bastiaan


> 
> 
> -Steve
> 
> 
> 
> -- 
> by Rocket to the Moon,
> by Airplane to the Rocket,
> by Taxi to the Airport,
> by Frontdoor to the Taxi,
> by throwing back the blanket and laying down the legs ...
> - They Might Be Giants
> 
> 
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 

[Cppunit-devel] another configure.in change

[Steve M. R. <ste...@vi...>]

I just noticed another oddity in configure.in that violates
the principle of "least surprise".  I propose we do away
with the following:

AC_ARG_ENABLE(debug-mode,   
[  --enable-debug-mode     enable debugging mode],
  [
    CFLAGS="-D_DEBUG -g3 -Wall"
    CXXFLAGS="-D_DEBUG -g3 -Wall"
  ],[
    CFLAGS="-O2 "
    CXXFLAGS="-O2"
  ]) 

Rationale: besides surprising me that "-g" is omitted by default, it
is clearly wrong that --enable-debug-mode sets GCC-specific flags like
"-Wall".  The builder always has the option to set the flags themself,
so this difference is completely gratuitous.

-Steve


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

[Cppunit-devel] 2. configure.in queries

[Steve M. R. <ste...@vi...>]

Would anyone object to the following two changes to configure.in?

1. remove AM_DISABLE_STATIC

Rationale: libtool-based packages typically build both shared and
static libs by default (configure has --disable-static &
--disable-shared flags for the installer to customize to her taste).
The principle of "least surprise" dictates that we stick to that
unless there is a compelling reason for NOT building static
libcppunit.a.  Is there such a reason?

2. bump the version string to 1.5.6

Rationale: to differentiate CVS cppunit from the last released
version.  


-Steve



-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: [Cppunit-devel] include directory clean-up

[Steve M. R. <ste...@vi...>]

Hi,

Just a note to say that I checked in the changes to 
replace
	CPPUNIT_USE_TYPEINFO
with
	CPPUNIT_USE_TYPEINFO_NAME

as we discussed some time back.

I changed all the sources and headers.  I didn't change the .dsp
files, as they say "DO NOT EDIT".  Should I edit them anyway?
Should these .dsp files be defining such symbols anyway?  I thought
the symbols should be defined in the config-xxx.h files?

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

[Cppunit-devel] Test Plug In Technology

[Baptiste L. <bl...@cl...>]

    Some of you might have noticed, yesterday I committed a new feature for
the VC++ Platform.

    * What it is ?

    It is a test runner (named test plug in runner) that can load and run
test contains in a DLL that implement a specific interface. The nifty thing
is the test runner can reload the DLL. A feature that is to be implemented
is that the reload and test run would be automatic: if the DLL is modified
then it is reloaded and the test are run.
    The name test plug in came from the fact that the technic use there is
similar to the one used when writing plug-ins (at least, I believe so).

    * How do I use it ?

    Your DLL must be a standard WIN32 DLL, not an MFC extension (I don't
know if it is possible to load/unload them like I'm doing for the plug-in).
It must be linked against the same Run-time as the test plug in runner
(still those memory allocation/deallocation problem). Finally, the DLL must
export a function that is defined as follow:


extern "C" {
  TESTPLUGIN_API TestPlugInInterface *GetTestPlugInInterface();
}

TESTPLUGIN_API is a symbol created by VC++ Wizard, that expand to
"__declspec(dllexport)" when you are building the DLL.

The TestPlugInInterface class is defined in
include/msvc6/testrunner/TestPlugInInterface.h.

You must subclass that class in your DLL and implement the only virtual
method it has:
  CppUnit::Test *makeTest();

You guessed it, that method must return the test that will be used by the
test runner.

The example examples\msvc6\TestPlugIn\ demonstrate how to create a test
plug-in.

The test plug in runner is in src\msvc6\testpluginrunner. It still need work
(being able to save the configuration, managing multiple configurations, and
the automatic reload & run feature).

Ideas & comments are welcome,
Baptiste.

---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Author of The Text Reformatter, a tool for fanfiction readers and writers.
Language: English, French (Well, I'm French).

RE: [Cppunit-devel] Directory structure...

[Bastiaan B. <bas...@li...>]

Hi Baptiste,

Sorry for my late reply, I was just busy when I got your messages and
managed to let them end up in the wrong mail folder. 
Anyway I agree with your proposals to rearrange the header files in cppunit,
cppunit/extensions and cppunit/helpers directories. For the UI header the
cppunitui/text, etc. arrangment makes most sense to me. It immediately makes
clear the UI stuff is separate from the actual framework. 

Good luck,

Bastiaan
 
> -----Oorspronkelijk bericht-----
> Van: Baptiste Lepilleur [mailto:gai...@fr...]
> Verzonden: Monday, June 25, 2001 7:00 PM
> Aan: Cpp Unit Develpment Mailing List
> Onderwerp: [Cppunit-devel] Directory structure...
> 
> 
>   I never got any reply to my previous mails concerning the directory 
> structure. Was there something wrong with them, or are you 
> just busy ? We need 
> to come up with something...
> 
> Baptiste.
> 
> ---
> Baptiste Lepilleur <gai...@fr...>
> http://gaiacrtn.free.fr/index.html
> Language: English, French
> 
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 

[Cppunit-devel] Directory structure...

[Baptiste L. <gai...@fr...>]

  I never got any reply to my previous mails concerning the directory 
structure. Was there something wrong with them, or are you just busy ? We need 
to come up with something...

Baptiste.

---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/index.html
Language: English, French

Re: [Cppunit-devel] config-msvc6.h

[Bastiaan B. <bas...@li...>]

"Steve M. Robbins" wrote:

> On Wed, Jun 20, 2001 at 01:19:11PM +0200, Bastiaan Bakker wrote:
> >
> >
> > > -----Oorspronkelijk bericht-----
> > > Van: Baptiste Lepilleur [mailto:bl...@cl...]
> > > Verzonden: Monday, June 18, 2001 11:25 PM
> > > Aan: Cpp Unit Develpment Mailing List
> > > Onderwerp: [Cppunit-devel] config-msvc6.h
> > >
> > >
> > > Well, I tuned the config file for VC++. It works just fine !
> > >
> > > In the file, I found the following piece of code:
> > >
> > > /* Name of package */
> > > #ifndef CPPUNIT_PACKAGE
> > > #define CPPUNIT_PACKAGE  "cppunit"
> > > #endif
> > >
> > > /* Version number of package */
> > > #ifndef CPPUNIT_VERSION
> > > #define CPPUNIT_VERSION  "1.5.5"
> > > #endif
> > >
> > > Shouldn't those be common to any platforms (e.g. defined in
> > > Portability.h)
> > >
> >
> > They *are* common to all platforms, but they end up in
> > include/cppunit/config-auto.h through config/config.h.
> > But of course we can get them in Portability.h as well, with help of a
> > Portability.h.in. I see if I have time to fix it tonight.
>
> That's not going to help Baptiste!
>
> If we derive Portability.h from Portability.h.in, then no
> Portability.h should be shipped (normally).  That brings us back to
> the original problem that prompted Portability.h: either Portability.h
> is shipped (possibly bad for autoconf?) or folks on non-autoconf
> platforms need to copy Portability.h.in -> Portability.h and edit.
> This brings no advantage to the current scheme that I can see.
>

This is not the same as theo original problem, because both symbols have
identical values for all platforms.
But I see having a Portabilitity.h.in and shipping Portability.h is
confusing. I'll leave it as is.

>
> > Not that we use these macro's anywhere :-)
>
> Then we could simply ignore them!  Omit PACKAGE and VERSION from the
> conf-xxx.h files entirely.

Yeah, let's ignore them. I'll start now... :-)

Bastiaan

Re: [Cppunit-devel] autoconf version

[Steve M. R. <ste...@vi...>]

On Wed, Jun 20, 2001 at 10:53:01AM +0200, Volker Boerchers wrote:
> Hi,
> 
> I tried to build the recent CVS version of cppunit and ran into some
> problems due to the autoconf version requirement in autogen.sh
> (btw. autogen is not mentioned in the docs)

I've checked-in README.CVS to alleviate this.
 
>   $ ./autogen.sh 
>   Putting files in AC_CONFIG_AUX_DIR, `config'.
>   FATAL ERROR: Autoconf version 2.50 or higher is required for this script
>   automake: configure.in: installing `config/install-sh'
>   automake: configure.in: installing `config/mkinstalldirs'
>   automake: configure.in: installing `config/missing'
>   configure.in: 41: required file `config/config.h.in' not found
>   FATAL ERROR: Autoconf version 2.50 or higher is required for this script
>   $ autoconf --version
>   Autoconf version 2.13

Oops.  autoconf shouldn't run if automake already failed.
I changed autogen.sh to fix this.
 

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: [Cppunit-devel] config-msvc6.h

[Steve M. R. <ste...@vi...>]

On Wed, Jun 20, 2001 at 01:19:11PM +0200, Bastiaan Bakker wrote:
> 
> 
> > -----Oorspronkelijk bericht-----
> > Van: Baptiste Lepilleur [mailto:bl...@cl...]
> > Verzonden: Monday, June 18, 2001 11:25 PM
> > Aan: Cpp Unit Develpment Mailing List
> > Onderwerp: [Cppunit-devel] config-msvc6.h
> > 
> > 
> > Well, I tuned the config file for VC++. It works just fine !
> > 
> > In the file, I found the following piece of code:
> > 
> > /* Name of package */
> > #ifndef CPPUNIT_PACKAGE 
> > #define CPPUNIT_PACKAGE  "cppunit" 
> > #endif
> > 
> > /* Version number of package */
> > #ifndef CPPUNIT_VERSION 
> > #define CPPUNIT_VERSION  "1.5.5" 
> > #endif
> > 
> > Shouldn't those be common to any platforms (e.g. defined in 
> > Portability.h)
> >
> 
> They *are* common to all platforms, but they end up in
> include/cppunit/config-auto.h through config/config.h. 
> But of course we can get them in Portability.h as well, with help of a
> Portability.h.in. I see if I have time to fix it tonight.

That's not going to help Baptiste!  

If we derive Portability.h from Portability.h.in, then no
Portability.h should be shipped (normally).  That brings us back to
the original problem that prompted Portability.h: either Portability.h
is shipped (possibly bad for autoconf?) or folks on non-autoconf
platforms need to copy Portability.h.in -> Portability.h and edit.
This brings no advantage to the current scheme that I can see.

> Not that we use these macro's anywhere :-)

Then we could simply ignore them!  Omit PACKAGE and VERSION from the
conf-xxx.h files entirely.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

RE: [Cppunit-devel] config.h changes committed

[Bastiaan B. <bas...@li...>]

> -----Oorspronkelijk bericht-----
> Van: Baptiste Lepilleur [mailto:bl...@cl...]
> Verzonden: Monday, June 18, 2001 9:53 PM
> Aan: cpp...@li...
> Onderwerp: Re: [Cppunit-devel] config.h changes committed
> 
> 
> ----- Original Message -----
> From: "Steve M. Robbins" <ste...@vi...>
> To: <cpp...@li...>
> Sent: Monday, June 18, 2001 7:20 PM
> Subject: Re: [Cppunit-devel] config.h changes committed
> 
> 
> > On Mon, Jun 18, 2001 at 05:16:36PM +0200, Baptiste Lepilleur wrote:
> > > Quoting "Steve M. Robbins" <ste...@vi...>:
> > >   OK. I did know what's was behind the RTTI thingy (kinda 
> strange, I did
> not
> > > though that you could have the type_info without dynamic_cast).
> >
> > All I'm saying is that the macro defines HAVE_RTTI based on the
> > presence of typeid().  You are probably right that dynamic_cast is
> > present if typeid() is present; I don't know much about 
> RTTI.  It may
> > be that the reverse is not true, however.  My instinct is to assume
> > dynamic_cast is available, if needed, (and without checking) until
> > someone tells us otherwise.
>     OK.
> 

Yes, AFAIK, having typeid() equals having dynamic_cast equals having
HAVE_RTTI. 

> > >   Well, I propose to keep USE_TYPEINFO.
> > >
> > >   Our USE_TYPEINFO could be defined as: you have typeinfo, and the
> name()
> > > methode return a human readable name (that last one can't 
> be tested by a
> > > machine unfortunately). So it's a stronger requirement 
> than HAVE_RTTI.
> >

Yes, I was mistaken in my previous mail. USE_TYPEINFO needs more than
HAVE_RTTI. So, let's keep it.

> > It's true that GCC can produce an ungainly type name like
> >
> >
> t23Triangle_3_Plane_3_test1ZQ24CGALt11Homogeneous2ZQ24CGAL4Gmp
> zZQ24CGALt8Quo
> tient1ZQ24CGAL4Gmpz.point_intersection
>   Yuck!!! Baastian, did you look up an explanation for this 
> from the gcc
> folks ? (name are still useful for debugging)
> 

I couldn't find any reasoning for the current g++ implementation in the
mailing list archive and I haven't contacted the maintainers yet. Now that
they have released GCC 3.0, they'll probably have more time for new features
/ functional improvements, so I'll try soon.

> > so the idea of perhaps not using that name has merit.  In that case,
> > the symbol might be more appropriately-named USE_TYPEINFO_NAME.  You
> > may still wish to use type_info structures to test equality of
> > types.
>     I agree, that name reveal the intention better.
> 

Agreed.

> >
> > I'll have to think about this.  There seem to be relatively few uses
> > of using type_info::name() at present, and I'm puzzled by 
> some of them.
> >
> > For example, what is the purpose of class 
> CppUnit::TypeInfoHelper?  Is
> > there some advantage to using a class rather than a simple function
> > CppUnit::getClassName() ?
>    Yes. I though that the class would grow, but it did not. 
> Actually, isn't
> that the only use of name() ?
> 
>     Baptiste.

Well, for debuggers the mangled name may be more interesting. But the
standard does not document any use for the name() method, so we can only
guess.

Bastiaan

RE: [Cppunit-devel] config-msvc6.h

[Bastiaan B. <bas...@li...>]

> -----Oorspronkelijk bericht-----
> Van: Baptiste Lepilleur [mailto:bl...@cl...]
> Verzonden: Monday, June 18, 2001 11:25 PM
> Aan: Cpp Unit Develpment Mailing List
> Onderwerp: [Cppunit-devel] config-msvc6.h
> 
> 
> Well, I tuned the config file for VC++. It works just fine !
> 
> In the file, I found the following piece of code:
> 
> /* Name of package */
> #ifndef CPPUNIT_PACKAGE 
> #define CPPUNIT_PACKAGE  "cppunit" 
> #endif
> 
> /* Version number of package */
> #ifndef CPPUNIT_VERSION 
> #define CPPUNIT_VERSION  "1.5.5" 
> #endif
> 
> Shouldn't those be common to any platforms (e.g. defined in 
> Portability.h)
>

They *are* common to all platforms, but they end up in
include/cppunit/config-auto.h through config/config.h. 
But of course we can get them in Portability.h as well, with help of a
Portability.h.in. I see if I have time to fix it tonight.
Not that we use these macro's anywhere :-)

Bastiaan

 
> Baptiste.
> ---
> Baptiste Lepilleur <gai...@fr...>   
> http://gaiacrtn.free.fr/index.html
> Author of The Text Reformatter, a tool for fanfiction readers 
> and writers.
> Language: English, French (Well, I'm French).
> 
> 
> 
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 

RE: [Cppunit-devel] autoconf version

[Bastiaan B. <bas...@li...>]

> -----Oorspronkelijk bericht-----
> Van: Volker Boerchers [mailto:boe...@we...]
> Verzonden: Wednesday, June 20, 2001 10:53 AM
> Aan: cpp...@li...
> Onderwerp: [Cppunit-devel] autoconf version
> 
> 
> Hi,
> 
> I tried to build the recent CVS version of cppunit and ran into some
> problems due to the autoconf version requirement in autogen.sh
> (btw. autogen is not mentioned in the docs)
> 
>   $ ./autogen.sh 
>   Putting files in AC_CONFIG_AUX_DIR, `config'.
>   FATAL ERROR: Autoconf version 2.50 or higher is required 
> for this script
>   automake: configure.in: installing `config/install-sh'
>   automake: configure.in: installing `config/mkinstalldirs'
>   automake: configure.in: installing `config/missing'
>   configure.in: 41: required file `config/config.h.in' not found
>   FATAL ERROR: Autoconf version 2.50 or higher is required 
> for this script
>   $ autoconf --version
>   Autoconf version 2.13
> 
> Then i searched for a newer version but on
>   http://sources.redhat.com/autoconf/
> it's stated that the current version of Autoconf actually is 2.13.
> 
> Any clue? I guess you're using some development version of
> autoconf. If you need some special macro it's probably better to

It is NOT a development version, they simply do not keep all their webpages
up to date. See 
http://www.gnu.org/directory/autoconf.html for confirmation. Since it
contains many improvements over 2.13, upgrading to it is probably well worth
the effort.  

> include it into cppunit for some time until the newer autoconf has
> made it into at least some linux distributions (just for convenience
> :-).

Well, I'm lazy, uhm I mean "don't have much time". So for convenience of the
project I prefer to settle for one autoconf version: saves us hunting
problems that turn out to be related to differences
between autoconf versions. 
The AC_CREATE_PREFIX_CONFIG_H originally contained a workaround for the lack
of AS_DIRNAME in 2.13, but it turned out to be broken. I did not want to
waste more time on compatiblity with an old autoconf version, especially
because it inconveniences only such a small group of people and not regular
CppUnit users.   

Sorry,

Bastiaan

PS. If you need a tar ball that includes aclocal.m4, etc., to get started,
just let me know.


> 
> Curious about the "new" cppunit...
> 
> Volker
> -- 
> Volker Boerchers, boe...@we...
> 
> 
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 

[Cppunit-devel] autoconf version

[Volker B. <boe...@we...>]

Hi,

I tried to build the recent CVS version of cppunit and ran into some
problems due to the autoconf version requirement in autogen.sh
(btw. autogen is not mentioned in the docs)

  $ ./autogen.sh 
  Putting files in AC_CONFIG_AUX_DIR, `config'.
  FATAL ERROR: Autoconf version 2.50 or higher is required for this script
  automake: configure.in: installing `config/install-sh'
  automake: configure.in: installing `config/mkinstalldirs'
  automake: configure.in: installing `config/missing'
  configure.in: 41: required file `config/config.h.in' not found
  FATAL ERROR: Autoconf version 2.50 or higher is required for this script
  $ autoconf --version
  Autoconf version 2.13

Then i searched for a newer version but on
  http://sources.redhat.com/autoconf/
it's stated that the current version of Autoconf actually is 2.13.

Any clue? I guess you're using some development version of
autoconf. If you need some special macro it's probably better to
include it into cppunit for some time until the newer autoconf has
made it into at least some linux distributions (just for convenience
:-).

Curious about the "new" cppunit...

Volker
-- 
Volker Boerchers, boe...@we...

Re: [Cppunit-devel] include directory clean-up

[Baptiste L. <bl...@cl...>]

Well, onward for the answer to the next part of the mail...
----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: <cpp...@li...>
Sent: Thursday, June 14, 2001 5:16 PM
Subject: Re: [Cppunit-devel] include directory clean-up


> On Thu, Jun 14, 2001 at 04:39:41PM +0200, Baptiste Lepilleur wrote:
> I'd like to start documenting the classes better.  I don't understand
> it well enough, yet, though.  If we can get some discussion going
> here, I will add the documentation strings.  I expect this process
> will clarify class relationships and groupings will emerge,
> facilitating directory/namespace structuring.
   OK. I'd rather not write doc because my written english is quite strange,
and I fear I would put more confusion in the mind of the user than anything
else.

> For example, we can start with the core classes such as Test,
> TestCase, TestCaller, TestSuite.  The latter three are each a subclass
> of Test, which is pure virtual.  Is it fair to say, then, that
> Test is an "interface" class?  What are the intended semantics
> of its methods: run(), countTestCases(), toString() and getName()?
> We just had some questions on whether the latter two should be
> merged.  I don't think a conclusion was reached.

Well, let's get started. I'll give you my view on this classes.

*** Test: provides a way to run a specified test and tracks the result of
the run.
void run (TestResult *result):
  - Run the test.
  - The test should report each stage of its run to the TestResult
(startTest/addError/addFailure/endTest).
  - Should never ever throw an exception except for the case of fatal errors
(can't allocate memory to add the failure to TestResult...)

int countTestCases () const:
  - predict the number of times the TestCase::runTest() method will be
called if this test is run(). Returning a value lower than 1 doesn't make
sense (what would be the point of running the test if no unit test is run?).

std::string toString () const:
  - My best guess would be describes the test. In Java, and Michael
Feather's original version there is no getName() method, and the toString()
has the role of the getName() method.

std::string getName () const:
  - Identify the test. The returned name should as unique as possible to
identify the test (that why the TestCase name is included by the
TestSuiteBuilder). TestRunners rely on that name to run a specified test (or
suite). Having a name that identify the test without ambiguity help reading
the failures report (you don't have to bother with the filename).

Conclusion: ditch either toString() or getName(). I find that getName() as a
more intention revealing name ;-)

*** TestCase: provides a convenient way to write test with a
setup/test/tearoff stage. Provides track of the test run to the TestResult.

void run(TestResult *result):
  - provides TestResult with progress of the test run.
  - run the actual test with the runTest() method which should be overrided.
Provides runTest() initialization with a setUp() method and clean up
tearOff() method which should be overrided to create/destroy fixtures (note
that creating fixture in the class constructor does not make it possible to
run the test more than 1 time if the fixture is modified by the test).
  - "translate" exception thrown by either setUp(), runTest() or tearOff()
into failure or error report to the TestResult. Exception with
CppUnit::Exception as a base class are "failure" (a failed condition, such
as a failed assertion or an uncaught excepted exception), report to the
TestResult with addFailure() other exception are "error", reported with
addError().

TestResult  *run():
  - a convenient method to run a test in the wild ? It's not used by the
framework itself. Only use I can see is if you want to run a test case
without a test runner.

TestResult *defaultResult():
  - used by the previous run() method. Should be overrided to use a test
result other than TestResult. Can't think of a use for those two...

int countTestCases() const:
  - always returns 1 since run() call runTest() only once. Should not be
overrided.

std::string getName() const (or toString() depending on the survivor ;-) ):
  - identifiy the test. Among all the classes this is the most important
implementation of this method since it is the one use by the TestResult (and
TestRunner) to indicate which test as failed. Should be unique, but it not
always possible (template test case on platform without RTTI support :-( ).

void setUp():
  - called by run() before calling runTest(). Should be override to
initialize the test. If an exception is throw, then runTest() and tearDown()
won't be called and an "error" is reported for that test.

void runTest():
  - you should override this method to do the actual test. Test failure
should be reported by throwing a exception derived from CppUnit::Exception.
This is the place where you use CPPUNIT_ASSERTs macros.

void tearDown():
  - you should override this method to clean up after runTest() is called.
This method is always called if setUp() has been called successfuly (no
exception were thrown).

That about it for those two nasties.

More about the other another day (note that test caller is a specialization
of TestCase).
I'll try to do a short synops when I'll be done with each of classes.

Good night,
Baptiste.

---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Author of The Text Reformatter, a tool for fanfiction readers and writers.
Language: English, French (Well, I'm French).

[Cppunit-devel] config-msvc6.h

[Baptiste L. <bl...@cl...>]

Well, I tuned the config file for VC++. It works just fine !

In the file, I found the following piece of code:

/* Name of package */
#ifndef CPPUNIT_PACKAGE 
#define CPPUNIT_PACKAGE  "cppunit" 
#endif

/* Version number of package */
#ifndef CPPUNIT_VERSION 
#define CPPUNIT_VERSION  "1.5.5" 
#endif

Shouldn't those be common to any platforms (e.g. defined in Portability.h)

Baptiste.
---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Author of The Text Reformatter, a tool for fanfiction readers and writers.
Language: English, French (Well, I'm French).

Re: [Cppunit-devel] config.h changes committed

[Baptiste L. <bl...@cl...>]

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: <cpp...@li...>
Sent: Monday, June 18, 2001 7:20 PM
Subject: Re: [Cppunit-devel] config.h changes committed


> On Mon, Jun 18, 2001 at 05:16:36PM +0200, Baptiste Lepilleur wrote:
> > Quoting "Steve M. Robbins" <ste...@vi...>:
> >   OK. I did know what's was behind the RTTI thingy (kinda strange, I did
not
> > though that you could have the type_info without dynamic_cast).
>
> All I'm saying is that the macro defines HAVE_RTTI based on the
> presence of typeid().  You are probably right that dynamic_cast is
> present if typeid() is present; I don't know much about RTTI.  It may
> be that the reverse is not true, however.  My instinct is to assume
> dynamic_cast is available, if needed, (and without checking) until
> someone tells us otherwise.
    OK.

> >   Well, I propose to keep USE_TYPEINFO.
> >
> >   Our USE_TYPEINFO could be defined as: you have typeinfo, and the
name()
> > methode return a human readable name (that last one can't be tested by a
> > machine unfortunately). So it's a stronger requirement than HAVE_RTTI.
>
> It's true that GCC can produce an ungainly type name like
>
>
t23Triangle_3_Plane_3_test1ZQ24CGALt11Homogeneous2ZQ24CGAL4GmpzZQ24CGALt8Quo
tient1ZQ24CGAL4Gmpz.point_intersection
  Yuck!!! Baastian, did you look up an explanation for this from the gcc
folks ? (name are still useful for debugging)

> so the idea of perhaps not using that name has merit.  In that case,
> the symbol might be more appropriately-named USE_TYPEINFO_NAME.  You
> may still wish to use type_info structures to test equality of
> types.
    I agree, that name reveal the intention better.

>
> I'll have to think about this.  There seem to be relatively few uses
> of using type_info::name() at present, and I'm puzzled by some of them.
>
> For example, what is the purpose of class CppUnit::TypeInfoHelper?  Is
> there some advantage to using a class rather than a simple function
> CppUnit::getClassName() ?
   Yes. I though that the class would grow, but it did not. Actually, isn't
that the only use of name() ?

    Baptiste.
---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Author of The Text Reformatter, a tool for fanfiction readers and writers.
Language: English, French (Well, I'm French).

Re: [Cppunit-devel] config.h changes committed

[Steve M. R. <ste...@vi...>]

On Mon, Jun 18, 2001 at 05:16:36PM +0200, Baptiste Lepilleur wrote:
> Quoting "Steve M. Robbins" <ste...@vi...>:
> 
> > On Mon, Jun 18, 2001 at 09:03:04AM +0200, Bastiaan Bakker wrote:
> > I am suggesting to eliminate one symbol in favour of the other.
> > If I have to choose, I would keep HAVE_RTTI because it has some
> > precedence: it comes from the autoconf macro archive.  But I can
> > see reasons for preferring to keep USE_TYPEINFO.

>   OK. I did know what's was behind the RTTI thingy (kinda strange, I did not 
> though that you could have the type_info without dynamic_cast).

All I'm saying is that the macro defines HAVE_RTTI based on the
presence of typeid().  You are probably right that dynamic_cast is
present if typeid() is present; I don't know much about RTTI.  It may
be that the reverse is not true, however.  My instinct is to assume
dynamic_cast is available, if needed, (and without checking) until
someone tells us otherwise.


>   Well, I propose to keep USE_TYPEINFO.
> 
>   Our USE_TYPEINFO could be defined as: you have typeinfo, and the name() 
> methode return a human readable name (that last one can't be tested by a 
> machine unfortunately). So it's a stronger requirement than HAVE_RTTI.

It's true that GCC can produce an ungainly type name like

    t23Triangle_3_Plane_3_test1ZQ24CGALt11Homogeneous2ZQ24CGAL4GmpzZQ24CGALt8Quotient1ZQ24CGAL4Gmpz.point_intersection

so the idea of perhaps not using that name has merit.  In that case,
the symbol might be more appropriately-named USE_TYPEINFO_NAME.  You
may still wish to use type_info structures to test equality of
types.

I'll have to think about this.  There seem to be relatively few uses
of using type_info::name() at present, and I'm puzzled by some of them.

For example, what is the purpose of class CppUnit::TypeInfoHelper?  Is
there some advantage to using a class rather than a simple function
CppUnit::getClassName() ?


-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: [Cppunit-devel] config.h changes committed

[Baptiste L. <gai...@fr...>]

Quoting "Steve M. Robbins" <ste...@vi...>:

> On Mon, Jun 18, 2001 at 09:03:04AM +0200, Bastiaan Bakker wrote:
> I am suggesting to eliminate one symbol in favour of the other.
> If I have to choose, I would keep HAVE_RTTI because it has some
> precedence: it comes from the autoconf macro archive.  But I can
> see reasons for preferring to keep USE_TYPEINFO.
  OK. I did know what's was behind the RTTI thingy (kinda strange, I did not 
though that you could have the type_info without dynamic_cast).
  Well, I propose to keep USE_TYPEINFO.

  Our USE_TYPEINFO could be defined as: you have typeinfo, and the name() 
methode return a human readable name (that last one can't be tested by a 
machine unfortunately). So it's a stronger requirement than HAVE_RTTI.


> >    When you want maximum portability, you want to disable both.
> 
> I think it is more correct to say, "for maximum portability, you want
> the library to work in both the presence and the absence of HAVE_RTTI".
  The library works on both, but some features won't be available (name 
extraction from type. We had rather lengthy discussion about this with Baastian 
a while back). The good things is that is you are using the macro, you don't 
have to care.
  So if I have a crossplatform project, I can remove USE_TYPEINFO support to 
make sure than only portable features are used.

> The symbol HAVE_RTTI is checked for and set automatically at
> installation time.  Assuming it replaces USE_TYPEINFO, HAVE_RTTI
> should not be an option for the library user.  That is, it should not
> appear in <cppunit/Portability.h>.  Among other reasons, you can run
> into trouble if the installer builds with HAVE_RTTI = 1 (enabling RTTI
> in the library .cpp files), and the user includes <cppunit/foo> with
> HAVE_RTTI = 0 (not using RTTI in some inlined functions).  Or
> vice-versa.
  I agree

---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/index.html
Language: English, French

Re: [Cppunit-devel] config.h changes committed

[Steve M. R. <ste...@vi...>]

On Mon, Jun 18, 2001 at 09:03:04AM +0200, Bastiaan Bakker wrote:

> Ad. 1) My idea for config-msv6.h, etc. is that they are but replacements for
> config-auto.h: they just set some preprocessor switches and don't do
> anything else. This way it's simple to verify whether they are still
> complete with respect to config-auto.h.
> Portability.h then should contain all workarounds and hacks necessary, based
> on the switches in config-*.h
> In short: the _MSC_VER in Portability.h was intentional. 

OK.  I was worrying that a section of "#if COMPILER_X" blocks could become
a rat's nest of unreadable code.  Clearly it isn't, yet.  I won't mention
this again unless it does become one.

 
On Mon, Jun 18, 2001 at 09:38:03AM +0200, Baptiste Lepilleur wrote:

> > 3.  Is it useful to have CPPUNIT_USE_TYPEINFO as well as
> > CPPUNIT_HAVE_RTTI?  Certainly you can't define the former without the
> > latter.  Would you ever WANT to disable using RTTI, if available?  If
> > not, then we can eliminate USE_TYPEINFO in favour of HAVE_RTTI.  If
> > disabling it _is_ deemed useful, then the same comment about the extra
> > symbol applies; the stanza can be simplified to
> >
> > #ifndef CPPUNIT_USE_TYPEINFO
> > #define CPPUNIT_USE_TYPEINFO 1
> > #endif
>
>     HAVE_RTTI say that you can do dynamic_cast<...>, USE_TYPEINFO
>     say that typeinfo.name() returns a "human readable" name that
>     can be used to identify test case.

It seems that have a disagreement on definitions.  The autoconf test
in config/ac_cxx_rtti says

	If the compiler supports Run-Time Type Identification 
	(typeinfo header and typeid keyword), define HAVE_RTTI.

And, indeed, those are the two features tested for by the macro.
In particular, HAVE_RTTI says nothing about the presence or
absence of dynamic_cast.  

[There is another macro in the archive for HAVE_DYNAMIC_CAST, if we
need it.  But I don't think we do.  There are only two instances of
dynamic cast in the current sources, and both are in msv6/testrunner.]

The symbol HAVE_RTTI is nowhere used.

The symbol USE_TYPEINFO, on the other hand, is used in a few places
as a guard around code that uses typeid().  Interestingly, it
does not guard #include <typeinfo>.  In short, USE_TYPEINFO is
being used precisely as HAVE_RTTI *should* be used.

I am suggesting to eliminate one symbol in favour of the other.
If I have to choose, I would keep HAVE_RTTI because it has some
precedence: it comes from the autoconf macro archive.  But I can
see reasons for preferring to keep USE_TYPEINFO.


>    When you want maximum portability, you want to disable both.

I think it is more correct to say, "for maximum portability, you want
the library to work in both the presence and the absence of HAVE_RTTI".

The symbol HAVE_RTTI is checked for and set automatically at
installation time.  Assuming it replaces USE_TYPEINFO, HAVE_RTTI
should not be an option for the library user.  That is, it should not
appear in <cppunit/Portability.h>.  Among other reasons, you can run
into trouble if the installer builds with HAVE_RTTI = 1 (enabling RTTI
in the library .cpp files), and the user includes <cppunit/foo> with
HAVE_RTTI = 0 (not using RTTI in some inlined functions).  Or
vice-versa.


On Mon, Jun 18, 2001 at 09:03:04AM +0200, Bastiaan Bakker wrote:
> Ad. 3) The fact that the compiler can do RTTI doesn't always mean
> you want to have it, for example when you have very tight
> environment, or the implementation is broken, etc. Anyway it seems
> useless to have multiple symbols: a --disable-rtti switch in
> autoconf could disable RTTI on the compiler and unset HAVE_RTTI.

I agree.

-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

RE: [Cppunit-devel] config.h changes committed

[Baptiste L. <gai...@fr...>]

Quoting Bastiaan Bakker <bas...@li...>:

> > 2.  Which way should the "naked assert" default?  I thought the
> > consensus was to NOT define assert() by default.  However,
> > Portability.h enables them by default.  More importantly, the header
> > introduces an extra symbol, which I think is unnecessary.  We could
> > write it as
> > 
> > 	#ifndef CPPUNIT_ENABLE_NAKED_ASSERT
> > 	#define CPPUNIT_ENABLE_NAKED_ASSERT 0[*]
> > 	#endif
> > 
> > [*] or 1, depending on the default desired.
  Naked assert should be disabled by default. I don't remember why I wrote this 
like that (the weirdest stuff is that I remember having to make the change to 
the CPPUNIT macros in one of my project because the naked assert where not 
defined?!?).
  The logic behind this, is that you may need some day to use a third-party 
library which rely on or define "assert". If the user want a shorter form to 
write assertion (CPPUNIT_ASSERT_EQUAL is quite verbose), aliases to cppunit 
macros can easily be defined.

Baptiste.

---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/index.html
Language: English, French

Re: [Cppunit-devel] config.h changes committed

[Baptiste L. <bl...@cl...>]

> 3.  Is it useful to have CPPUNIT_USE_TYPEINFO as well as
> CPPUNIT_HAVE_RTTI?  Certainly you can't define the former without the
> latter.  Would you ever WANT to disable using RTTI, if available?  If
> not, then we can eliminate USE_TYPEINFO in favour of HAVE_RTTI.  If
> disabling it _is_ deemed useful, then the same comment about the extra
> symbol applies; the stanza can be simplified to
>
> #ifndef CPPUNIT_USE_TYPEINFO
> #define CPPUNIT_USE_TYPEINFO 1
> #endif
    HAVE_RTTI say that you can do dynamic_cast<...>, USE_TYPEINFO say that
typeinfo.name() returns a "human readable" name that can be used to identify
test case.

   When you want maximum portability, you want to disable both.

  Baptiste.
---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Author of The Text Reformatter, a tool for fanfiction readers and writers.
Language: English, French (Well, I'm French).

RE: [Cppunit-devel] config.h changes committed

[Bastiaan B. <bas...@li...>]

> -----Oorspronkelijk bericht-----
> Van: Steve M. Robbins [mailto:ste...@vi...]
> Verzonden: Monday, June 18, 2001 4:29 AM
> Aan: cpp...@li...
> Onderwerp: Re: [Cppunit-devel] config.h changes committed
> 
> 
> On Mon, Jun 18, 2001 at 01:17:03AM +0200, Bastiaan Bakker wrote:
> > "Steve M. Robbins" wrote:
> > 
> > > On Sun, Jun 17, 2001 at 10:20:16PM +0200, Bastiaan Bakker wrote:
> 
> > > > * use  autoconf 2.40 or higher to rebuild aclocal.m4, 
> because the
> > > > AC_CREATE_PREFIX_CONFIG_H macro needs the AS_DIRNAME macro.
> > >
> > > I expect you meant "2.50" ?
> > 
> > The docs somewhere stated that AS_DIRNAME has been included in 2.40.
> > Don't know whether that's a public release or not, or that it was a
> > typo. I'm using 2.50 myself.
> 
> Interesting.  There was no public 2.40, certainly.  In fact, there is
> no mention of 2.40 anywhere in the autoconf NEWS or ChangeLog files
> that I can find.
> 

Now that I think of it, 2.40 very likely was mentioned in the docs to the 
> 
> > > > * include <cppunit/Portability.h> instead of <cppunit/config.h>
> 
> Looks good.
> 
> About Portability.h, I have three questions.
> 
> 
> 1.  Shouldn't this bit go into config-msvc6.h?
> 
> 	#if _MSC_VER > 1000     // VC++
> 	#pragma once
> 	#pragma ...
> 
> 
> 2.  Which way should the "naked assert" default?  I thought the
> consensus was to NOT define assert() by default.  However,
> Portability.h enables them by default.  More importantly, the header
> introduces an extra symbol, which I think is unnecessary.  We could
> write it as
> 
> 	#ifndef CPPUNIT_ENABLE_NAKED_ASSERT
> 	#define CPPUNIT_ENABLE_NAKED_ASSERT 0[*]
> 	#endif
> 
> [*] or 1, depending on the default desired.
> 
> 
> 
> 3.  Is it useful to have CPPUNIT_USE_TYPEINFO as well as
> CPPUNIT_HAVE_RTTI?  Certainly you can't define the former without the
> latter.  Would you ever WANT to disable using RTTI, if available?  If
> not, then we can eliminate USE_TYPEINFO in favour of HAVE_RTTI.  If
> disabling it _is_ deemed useful, then the same comment about the extra
> symbol applies; the stanza can be simplified to
> 
> 	#ifndef CPPUNIT_USE_TYPEINFO
> 	#define CPPUNIT_USE_TYPEINFO 1
> 	#endif
> 
>

Ad. 1) My idea for config-msv6.h, etc. is that they are but replacements for
config-auto.h: they just set some preprocessor switches and don't do
anything else. This way it's simple to verify whether they are still
complete with respect to config-auto.h.
Portability.h then should contain all workarounds and hacks necessary, based
on the switches in config-*.h
In short: the _MSC_VER in Portability.h was intentional. 

Ad. 2, 3) The code fragments for CPPUNIT_USE_NAKED_ASSERT and
CPPUNIT_USE_TYPEINFO were copied verbatim from include/cppunit/config.h.in,
so their settings are not new and do not express my opinion on how they
should be.

Ad. 2) I agree, the naked assert should be off by default.

Ad. 3) The fact that the compiler can do RTTI doesn't always mean you want
to have it, for example when you have very tight environment, or the
implementation is broken, etc. Anyway it seems useless to have multiple
symbols: a --disable-rtti switch in autoconf could disable RTTI on the
compiler and unset HAVE_RTTI.
 

Bastiaan

Re: [Cppunit-devel] config.h changes committed

[Steve M. R. <ste...@vi...>]

On Mon, Jun 18, 2001 at 01:17:03AM +0200, Bastiaan Bakker wrote:
> "Steve M. Robbins" wrote:
> 
> > On Sun, Jun 17, 2001 at 10:20:16PM +0200, Bastiaan Bakker wrote:

> > > * use  autoconf 2.40 or higher to rebuild aclocal.m4, because the
> > > AC_CREATE_PREFIX_CONFIG_H macro needs the AS_DIRNAME macro.
> >
> > I expect you meant "2.50" ?
> 
> The docs somewhere stated that AS_DIRNAME has been included in 2.40.
> Don't know whether that's a public release or not, or that it was a
> typo. I'm using 2.50 myself.

Interesting.  There was no public 2.40, certainly.  In fact, there is
no mention of 2.40 anywhere in the autoconf NEWS or ChangeLog files
that I can find.


> > > * include <cppunit/Portability.h> instead of <cppunit/config.h>

Looks good.

About Portability.h, I have three questions.


1.  Shouldn't this bit go into config-msvc6.h?

	#if _MSC_VER > 1000     // VC++
	#pragma once
	#pragma ...


2.  Which way should the "naked assert" default?  I thought the
consensus was to NOT define assert() by default.  However,
Portability.h enables them by default.  More importantly, the header
introduces an extra symbol, which I think is unnecessary.  We could
write it as

	#ifndef CPPUNIT_ENABLE_NAKED_ASSERT
	#define CPPUNIT_ENABLE_NAKED_ASSERT 0[*]
	#endif

[*] or 1, depending on the default desired.



3.  Is it useful to have CPPUNIT_USE_TYPEINFO as well as
CPPUNIT_HAVE_RTTI?  Certainly you can't define the former without the
latter.  Would you ever WANT to disable using RTTI, if available?  If
not, then we can eliminate USE_TYPEINFO in favour of HAVE_RTTI.  If
disabling it _is_ deemed useful, then the same comment about the extra
symbol applies; the stanza can be simplified to

	#ifndef CPPUNIT_USE_TYPEINFO
	#define CPPUNIT_USE_TYPEINFO 1
	#endif


-S




-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants