Re: Solving the config.h nightmare ?

[Daniel Reed]

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 <address@hidden>      http://shell.n.ml.org/n/        
http://naim.n.ml.org/
It is a miracle that curiosity survives formal education. -- Albert
Einstein, Physicist