Re: bison-20001221

[Hans Aberg]

At 17:28 +0100 1-01-12, Akim Demaille wrote:
>   Configuration Header Files
>   ==========================
>
>      When a package tests more than a few C preprocessor symbols, the
>   command lines to pass `-D' options to the compiler can get quite long.
>   This causes two problems.  One is that the `make' output is hard to
>   visually scan for errors.  More seriously, the command lines can exceed
>   the length limits of some operating systems.  As an alternative to
>   passing `-D' options to the compiler, `configure' scripts can create a
>   C header file containing `#define' directives.  The `AC_CONFIG_HEADERS'
>   macro selects this kind of output.  It should be called right after
>   `AC_INIT'.
>

I quote here from the C++ standard 16.2:2-3 (I figure the C standard is
pretty much the same:

2 A preprocessing directive of the form
# include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header
identified uniquely by the specified sequence between the < and >
delimiters, and causes the replacement of that directive by the entire
contents of the header. How the places are specified or the header
identified is implementation-defined.

3 A preprocessing directive of the form
# include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the
source file identified by the specified sequence between the " delimiters.
The named source file is searched for in an implementation-defined manner.
If this search is not supported, or if the search fails, the directive is
reprocessed as if it read
# include <h-char-sequence> new-line
with the identical contained sequence (including > characters, if any) from
the original directive.

So formally, all it says that #include "..." also as a second attempt
searches as the #include <...> directive does. However, in practise the
extra "..." places are "local" places, and the <...> places are "standard"
places (the standard headers are all found in the <...> places.

So the first question is always, where is the user expected to put the
header before compilation: If it is among the "standard" places, use the
<...> directive, if it is a "local" file, use the "..." directive.

Now, over to config.h: It seems me that this is not a library file, but a
local file only belonging to the project. If one has several projects, each
may have an identically named file, config.h, so putting them among the
standard files, where every project has access to them seems to be a bad
idea. Thus put it among the "local" files.

Now, if config.h is put among the "local" files, and it is included using
<...>, then it is evidently something wrong with the compiler. :-)

>#     The package should `#include' the configuration header file before
>#  any other header files, to prevent inconsistencies in declarations (for
>#  example, if it redefines `const').  Use `#include <config.h>' instead
>#  of `#include "config.h"', and pass the C compiler a `-I.' option (or
>#  `-I..'; whichever directory contains `config.h').  That way, even if
>#  the source directory is configured itself (perhaps to make a
>#  distribution), other build directories can also be configured without
>#  finding the `config.h' from the source directory.

The situation described here seems to be that a directory with a `config.h'
file is used as a source directory, and one wants to build it from another
directory using a different `config.h' file. This will then work if one is
using a compiler having a `-I' option, but not otherwise. -- I figure that
this option adds the named directory to the standard search places.

-- Perhaps one wants to make it possible to make several different builds
from the same directory by only changing the "config.h" file, without
having to remove the original "config.h" file.

Does GCC have the ability of using a file prefix -- a file that is read
before any other file is read. If so, an alternative approach would be to
compile with config.h as such a file prefix. It would then not be included
from any file, as the compiler includes it.

  Hans Aberg