Re: Use of config.h: summary of responses.

[Daniel Reed]

On 2004-09-13T12:23+0100, Dale Mellor wrote:
)    But if you can't install them, you can't include them in your
)    public headers. If you can't include them in public headers they
)    have to be written to a base-level platform (e.g. no use of const
)    keyword), but then the sources have to be written the same

The presence or lack of a "const" keyword is a compiler-specific
[build-environment-specific] attribute, not a system-specific attribute.

Consider:

Build and install a piece of software, libexample, using a compiler that
lacks "const". One of the header files included as part of your libexample
installation includes a workaround for a lack of const (such as defining it
away).

Install a different or updated compiler that *does* support the const
keyword.

Build and install a piece of software, example-tool, using this new
compiler. What is the behavior of the use of "const"?

(It is arguably not reasonable for the autotools to detect workarounds from
previous versions of themselves (present through the header files of a
dependency of the current project, or a dependency of a dependency, etc.)
and work around them.)


It is a good practice to require that compiler-specific attributes, and, in
many cases, even system-specific attributes be detected or re-detected per
build.

(I would even prefer if more system-specific attributes, such as the
presence or lack of optional extension-providing libraries, could be
detected at *runtime*.)

-- 
Daniel Reed <address@hidden>    http://people.redhat.com/djr/   
http://naim.n.ml.org/
If nature has made you a giver, your hands are born open, and so is
your heart. And though there may be times when your hands are empty,
your heart is always full, and you can give things out of that. --
Frances Hodgson Burnett, Novelist