RE: [Cppunit-devel] config.h proposal

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

> -----Oorspronkelijk bericht-----
> Van: Steve M. Robbins [mailto:ste...@vi...]
> Verzonden: Friday, June 08, 2001 3:49 PM
> Aan: cpp...@li...
> Onderwerp: Re: [Cppunit-devel] config.h proposal
> 
> 
> On Fri, Jun 08, 2001 at 02:37:31PM +0200, Bastiaan Bakker wrote:
> > Hi,
> >  
> > In order to cleanup the current config.h problems I like to 
> propose the
> > following approach, which is the one we also use in the 
> log4cpp project:
> >  
> > * As usual we let autoconf & friends generate 
> include/config.h.in and
> > include/config.h. Neither will be committed to CVS, 
> include/config.h.in will
> > end up in the dist tar. No CppUnit source file (i.e. *.cpp) 
> shall include
> > <config.h>.
> > * With the AC_CREATE_PREFIX_CONFIG_H macro (see
> > http://cryp.to/autoconf-archive/ 
> <http://cryp.to/autoconf-archive/> ) we let
> > autoconf generate include/cppunit/config.h from 
> include/config.h. This file
> > is identical to include/config.h, except that every #define 
> will be prefixed
> > with CPPUNIT_, ie 'HAVE_SSTREAM' will become' CPPUNIT_HAVE_SSTREAM'.
> >  This file won't go into CVS or the dist tar either, but 
> will be installed
> > along with the other header files. 
> > * For platforms that do not have autoconf a copy of 
> include/cppunit/config.h
> > will be made, for example to 
> include/cppunit/config-msvc6.h. The maintainer
> > each platform will have to manually edit this file to the 
> correct settings
> > for that platform. Each such file will go in CVS, dist and install.
> > * We create a new file include/cppunit/Portability.h, 
> which, depending on
> > the platform will include either include/cppunit/config.h or
> > include/cppunit/config-<platform>.h. This file will contain global
> > portability fixes for the supported platforms, e.g. 
> std::ostringstream,
> > '#pragma warning( disable : 4786 )', etc. It can also hold 
> non autoconf
> > switches like CPPUNIT_USE_TYPEINFO. All other CppUnit 
> sources will include
> > this file. The file itself will go in CVS, dist and install.
> >  
> > Using this method we don't have to check in files like 
> include/config.h,
> > which may accidentally be overwritten by UNIX people. Also 
> the Windows folks
> > don't need to manually copy  files in order to get started. 
> > The only thing that does require attention is that people 
> when people add
> > autoconf tests and switches they update 
> include/cppunit/config-<platform>.h
> > too.
> 
> I like it!
> 

That's nice to hear!

> With regard to file naming schemes, I have two thoughts.
> 
> 1.  If no code will include the autoconf-generated file, then it
> doesn't need to be in the "include" directory.  In fact, it is
> perhaps less confusing if it is placed elsewhere.  Maybe autoconf
> could generate config/portability, and the prefix macro can build the
> final header file from that.
> 

Yes, it certainly is less confusing. 
The only reservation I have against it is that maybe we will need <config.h>
to protect against differences between configurations of CppUnit and the
applications using in it. 
In this scenario, if HAVE_CONFIG_H is defined we include <config.h> in
<cppunit/Portability.h> and compare the values of USE_BLA and
CPPUNIT_USE_BLA for incompatible differences. 
Even though there will be no differences when compiling CppUnit, we still
need to have the config.h file. 
Actually, now that I'm writing this down, I see it's a dumb idea: you don't
know which configuration checks the application performs because autoconf is
dumb enough not to tell you wether a feature is not present or the test has
not been performed. Both cases end up with HAVE_BLA undefined, grr.

So let's move include/config.h to config/.


> 2.  We could stick with a (more traditional?) <cppunit/config.h> if
> the auto-generated portability header uses the same naming scheme
> as the others, say "include/cppunit/config-auto.h".  In other words,

OK, sounds fair. It makes clear config-auto.h and config-msvc6.h, etc. are
on the same level.

> <cppunit/config.h> takes the role of the file that you called 
> <cppunit/portability.h>, and "auto" is just another platform.
> 

Because of the confusion the config.h name already has caused, I rather
avoid it. People may think that it is some product of autoconf, which it
isn't. Also I hope the capital P in <cppunit/Portability.h> may give people
a hint that it is a C++ header, not a C one.

> 
> Regardless of the naming scheme chosen, it improves on what we now
> have in several ways.  Go for it!
> 

OK, I will!

Thanks,

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
>