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 <n@xxxxxx> 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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
