On Sat, 22 Apr 2006, Olivier Boudeville wrote:
My problem is that it results in my main header file ('Ceylan.h')
depending on 'CeylanConfig.h' (a renamed 'config.h' thanks to
AC_CONFIG_HEADERS), i.e. some sub-headers *have* to include
'CeylanConfig.h' to enable/disable some portions of the exposed API
So if I build an executable on my system, where I have built your software
with one set of ./configure options, it (my executable) might not run on
someone else's system if he built your software with a different set of
options? That sucks.
(besides, some signatures have to mention types such as mode_t, pid_t,
size_t, pthread_mutex_t, etc. which results in the need of having #ifdef
HAVE_UNISTD_H, thus the config file).
If mode_t is always in <unistd.h>, why do you need to check for it at all?
If it's not always in <unistd.h>, is it possible it might move at some
point in the future, say if the system operator upgrades his libc? Why
would you test for something that is always true, and why would you
hardcode something in *your* header that doesn't depend on *your* software
(and hence should be constantly retested by all software to be built in
the future)?
It's almost always a mistake to install generated headers. Distribute an
.m4 with your software that [re]performs all of the checks that dependent
software will need to make. Install that instead of what is essentially
just the cached output of its run (which is what your config.h is,
whatever you prefer to call it) so dependent software devlopers can just
call OB_PROG_CEYLON in their configure.ac and get their own config.h files
(or CPPFLAGS or whatever mechanism they prefer) sanitized.
--
Daniel Reed <[EMAIL PROTECTED]> http://shell.n.ml.org/n/
http://naim.n.ml.org/
It is a miracle that curiosity survives formal education. -- Albert
Einstein, Physicist
_______________________________________________
Autoconf mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/autoconf
