Re: [Cppunit-devel] config.h proposal

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

> > 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.

    I don't really see a need for HAVE_CONFIG_H:
    If we don't detect VC++ 6.0, C++ builder..., then we default to
<config.h>.
    If needed, anoher project specific symbol such as CPPUNIT_HAVE_CONFIG_H
could be used to force the use of config.h. This symbol would need to be
defined in each user 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
>
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
>