Re: [Cppunit-devel] macros and templates

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

On Thu, Jun 07, 2001 at 10:44:17PM +0200, Baptiste Lepilleur wrote:
> ----- Original Message -----
> From: "Steve M. Robbins" <ste...@vi...>
> To: <cpp...@li...>
> Sent: Wednesday, June 06, 2001 3:56 PM
> Subject: Re: [Cppunit-devel] macros and templates
> > OK.  But here's the problem.  The file config.h is automatically
> > generated (by configure) from config.h.in.  So we don't ship with
> > config.h.  Can you write a small script (CONFIGURE.BAT?) for the benefit
> > of WIN systems that don't run configure, that will copy config.h.in
> > to config.h?

>     I'll do that for development time. But I'd like to have config-win32.h
> copied to config.h for the tar ball. It will make life a lot easier for
> Windows users and that file can easily be removed by the configure script on
> Unix.

That's an unorthodox approach, but it will likely work.
I'll try it out to see how configure copes with having 
a config.h file already there.

Can you write a single config-win32.h that works for all platforms
that don't use configure?  The problem of which I'm thinking is this:
items like CPPUNIT_USE_TYPEINFO may differ for different compilers
on windows.  (If not this example, then future additions to this
file may differ).  If the installer has to hand-edit the file
anyway --- to choose the appropriate options --- then why not ask
them to rename it as well.  You can provide customized config-msv6.h
config-borland.h, and whatever.

 
> > At the moment, there are in fact, TWO config.h files.  That's pretty
> > confusing, I agree.  They should have different names.
>     Yes that would make sense.
>     config-cppunit.h ?
>     config-portability.h ?
> 
> >
> > The two files serve different needs.  The original config.h is the
> > standard header that autoconf generates.  It is intended to contain
> > stuff needed for build-time portability.  The symbol HAVE_DLFCN_H is
> > defined, for example, for the benefit of libtool in creating dynamic
> > libraries.
>     Can you post a copy of that file ? 

It is include/config.h, generated from include/config.h.in.  The latter
is in CVS, so you have a copy.  The generated file, on my system
is 

/* include/config.h.  Generated automatically by configure.  */
/* include/config.h.in.  Generated automatically from configure.in by autoheader 2.13.  */

/* Define if you have the <dlfcn.h> header file.  */
#define HAVE_DLFCN_H 1

/* Name of package */
#define PACKAGE "cppunit"

/* Version number of package */
#define VERSION "1.5.5"

/* define if the compiler supports Run-Time Type Identification */
#define HAVE_RTTI 1

/* define to 1 if the compiler implements namespaces */
#define HAVE_NAMESPACES 1

/* define if library uses std::string::compare(string,pos,n) */
#define FUNC_STRING_COMPARE_STRING_FIRST 1


> Can it be done in such a way that
> when a symbol is define it indicate the exception rather than the
> "standard". That way I could leave the config file empty, and just add the
> symbol when the VC++ platform does not support some standard things.

Maybe.  I can't be sure this is going to always be the case.
I can guarantee, however, that the input file --- named config.h.in ---
will have some useful comments in it.  What you need to do is take
config.h.in, rename it to config.h, and edit it to suite your environment.

 
> > The other header, <cppunit/config.h>, is intended to be installed
> > along with the rest of the CppUnit header files.  It contains symbol
> > definitions, like CPPUNIT_USE_TYPEINFO, that are used in the other
> > CppUnit headers.  Some of these symbols are detected automatically at
> > configure time.  So, again, this file does not ship.  For systems
> > that can't use the configure script, alternate arrangements are needed.
>     Ah, I get it. The main difference is that we don't exactly install the
> library. There is no standard place for us to put it. So most of the time,
> we just add the include directory to the include path and use it from there.
> That why having the config.h sitting right in in the global include space is
> bothering me.

It's not in the global include space.  This file is <cppunit/config.h>.
It's private to cppunit, if you like.


> > For the example you give, an alternative is for the user to write an
> > assertion_traits class for complex numbers that provides a toleranced
> > "equals" method.  In fact, one could go the same route for doubles,
> > so I considered the idea of removing CPPUNIT_ASSERT_DOUBLES_EQUAL.
> > Bad idea?
>     I don't see how you can specify the tolerance for each assertion using
> the traits!?!

You can't.  That's the one feature of the current macro that traits
can't simulate.
 
>     It would be better to leave CPPUNIT_ASSERT_DOUBLES_EQUAL here. People
> might not be familiar with traits, and the macro is self explaining.

And, yes, the macro name is easy to understand.  :-)

-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