Hi Philip,
On Fri, 2007 Aug 31 16:49:20 +0100, Philip Hazel wrote:
>
> I obviously wasn't thinking straight when I allowed the #if HAVE_CONFIG_H
> thing, because now that I think about it, it is going to trip *me* up
> sometime in the future.
>
> The source of Exim (www.exim.org) imports a copy of the PCRE source
> files. This goes back to the early days, when PCRE was new and not
> likely to be found. One of these days it should be changed to use an
> installed version of the library, but that hasn't happened yet. I just
> copy in the lastest PCRE sources from time to time.
>
> I now realize that if I copy the latest (7.3) PCRE source files into
> the Exim source tree and try to compile, it won't work, because
> HAVE_CONFIG_H is not defined.
There's that, but then there's also a lot more source files in the
latest PCRE than I see in exim/src/pcre/. Is the HAVE_CONFIG_H issue
really that significant? It's just one -D directive, and anyone who
knows their way around these things will understand exactly why that's
there.
> I understand Daniel's point about people who want to configure using
> -Dwhatever instead of config.h, but perhaps the #ifdef is defaulted the
> wrong way round. It would be easier (and backwards compatible with
> earlier releases) if instead PCRE used #ifndef NO_CONFIG_H instead.
> After all, if somebody is using a slew of -Dwhatever, adding one more
> shouldn't make much difference.
Historically, multiple -Dfoo=bar directives were the norm. Then, as
projects became bigger, and command-line length limitations remained the
same, config headers became more frequent. That's why we have
HAVE_CONFIG_H and not NO_CONFIG_H (or e.g. DEFS_ON_COMMAND_LINE, not to
favor negative symbols).
> I am slightly tempted, therefore, to propose the following changes:
>
> (1) Change from HAVE_CONFIG_H to NO_CONFIG_H.
> (2) Change from <config.h> to "config.h".
> (3) Make sure it's all documented.
>
> However, I realize that HAVE_CONFIG_H is widely used in other software,
> so this is a cultural problem. Sigh. It seems to be part of the automake
> conventions, as it is apparently generated in the Makefile without being
> explicitly asked for. (It's in "configure", but not "configure.ac".)
#1 is definitely a matter of convention, embodied by the autoconf
software itself, and it would be very peculiar to do things differently
from the rest of the world here.
#2 is strictly a technical issue. If you use "", and you're doing an
out-of-source-tree build, and the source tree has a config.h file, then
your build will incorrectly use the source tree's config.h instead of
your own (because "" first looks in the same directory as the source
file being compiled, even if your -I directives specify otherwise).
It is unfortunate that <> gives the impression that config.h is some
kind of system/installed header file. But I argue that this bit of
semantic weirdness is the lesser evil, compared to doing the absolute
wrong thing in the above scenario. And that, I believe, is what is
behind the same recommendation in the Autoconf manual.
--Daniel
