Re: [Cppunit-devel] config.h proposal

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

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!

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.

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


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

-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