lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Placement of HAVE_CONFIG_H in 'config.hpp'


From: Vadim Zeitlin
Subject: Re: [lmi] Placement of HAVE_CONFIG_H in 'config.hpp'
Date: Wed, 2 Nov 2005 18:20:37 +0100

On Wed, 02 Nov 2005 15:31:52 +0000 Greg Chicares <address@hidden> wrote:

GC> Vadim--I've moved [1]
GC>   #if defined HAVE_CONFIG_H
GC>   #   include "config.h"
GC>   #endif // Using autoconf.
GC> slightly lower in 'config.hpp': it now follows a C++ namespace thing
GC> (I'm sure autoconf doesn't care about that) and the definitions of
GC> some 'LMI_*' macros (could autoconf possibly care about those?).

 It could, if we wanted to define them in configure too. In fact, I think
this would be preferrable if only because "__WIN32__" is not the right way
to detect MSW: the standard (i.e. Microsoft) symbol is _WIN32. Some
compilers predefine WIN32 too. Some predefine all of the versions. So it's
not that simple.

 While configure, of course, has the knowledge of the platform it's
building [makefiles for] building for, so it could define LMI_MSW
trivially. If we did this, we'd want to take the existing detection in
"ifndef HAVE_CONFIG_H" too.


GC> [I think 'config.h' can include standard headers.

 Normally it doesn't, it just #defines things.

GC> Is there anything in the following header that 'config.h' could
GC> possibly depend on?]

 No, config.h never depends on anything. Which is why it's best to include
it a.s.a.p. because like this the other code can rely on getting the right
HAVE_XXX definitions from it. As a matter of fact, the usual recommendation
is to start all files with #include "config.h" line.

GC> [Can I assume that 'config.h' would never conflict with the following?]
GC> 
GC>   #if defined __GNUC__ && __GNUC__ < 3
GC>   #   error Obsolete compiler not supported.
GC>   #endif // Ancient gcc compiler.
GC> 
GC>   #if defined __GNUC__
GC>   #   define LMI_GCC_VERSION \
GC>           (__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__)
GC>   #endif // Compiler is gcc.

 No, it won't. Again, we could detect gcc version in configure (and abort
then) if we wanted and it would probably be nicer to do it if only because
configure can give a better error message than #error directive. But right
now we don't do this and even if we did, it still wouldn't conflict with
anything.

GC> [Is there any reason to include 'config.h' before the following header?]
GC> 
GC>   #define OK_TO_INCLUDE_CONFIG_ALL_HPP
GC>   #include "config_all.hpp"
GC>   #undef OK_TO_INCLUDE_CONFIG_ALL_HPP

 I think config_all.hpp shouldn't be included at all when configure is
used. config.h already define LMI_COMPILER_PROVIDES_EXPM1/LOG1P if they're
supported (and it detects it much better than any compiler version checks)
and so we don't need to do it here.

GC> [Here's where I'd like to include 'config.h'; is that a problem?]
GC> 
GC>   #if !defined HAVE_CONFIG_H

 I think the best would be to do it like this:

// This header #includes standard headers in an unusual way, and must
// be #included before any standard headers are seen.
//
#include "platform_dependent.hpp"

#if defined __GNUC__ && __GNUC__ < 3
#   error Obsolete compiler not supported.
#endif // Ancient gcc compiler.

#if defined __GNUC__
#   define LMI_GCC_VERSION \
        (__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__)
#endif // Compiler is gcc.

#if defined HAVE_CONFIG_H
#   include "config.h"
#else
#define OK_TO_INCLUDE_CONFIG_ALL_HPP
#include "config_all.hpp"
#undef OK_TO_INCLUDE_CONFIG_ALL_HPP

... all the rest of the manual checks ...
#endif // Using autoconf/not using it


 Thanks,
VZ





reply via email to

[Prev in Thread] Current Thread [Next in Thread]