Re: [Cppunit-devel] config.h proposal
Brought to you by:
blep
Menu
▾
▴
Re: [Cppunit-devel] config.h proposal
|
From: Steve M. R. <ste...@vi...> - 2001-06-08 15:54:22
|
On Fri, Jun 08, 2001 at 04:30:01PM +0200, Bastiaan Bakker wrote: > > > > -----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> ... If you are suggesting that an installed header has #if HAVE_CONFIG_H #include <config.h> #endif then I am completely against it. I need to be able to use CppUnit in other projects, some of which use autoconf and therefore define HAVE_CONFIG_H. The behaviour of CppUnit should not change based on whether or not I use autoconf in my project. > ... 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. There are further problems. One might have built CppUnit using compiler X and then be using it in another project with compiler Y. The two compilers can have different idiosyncracies, which will be reflected in the config files for CppUnit and the project using it. > So let's move include/config.h to config/. OK. > > 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. Ah. Well, the meaning of the capital 'P' completely escaped this person :-) I'm completely used to having capital letters in C header names. I don't think the name is going to matter much to the user of CppUnit. A user will never have to include it directly, as I understand things. Only CppUnit headers will include it. Right? -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 |
