Re: Solving the config.h nightmare ?

[Olivier Boudeville]

Hi again,

I answered through the text :

Daniel Reed a écrit :

> 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.
>
Well, yes, I agree this might be less than perfect, but I think it is
the price to pay for portability issues. For example, either I just
accept the smallest subset of supported features among all the different
platforms I target (which might be quite restrictive), either I want to
be able to take advantage of some facilities such as multithreading,
file locks, regular expressions, symlinks, extended file attributes,
network, file descriptors, etc. that may or may not be available on a
specific platform. The point is that on a given platform "vanilla
builds" of the library (i.e. if the user did not insisted on messing
specifically with AC_ARG_ENABLE options) have all the same set of
features enabled (basically all the feature that can be supported).
Therefore your prebuilt executable should not have bad surprises (except
for classical ABI issues due to exception management, gcc versions,
etc.). Moreover such optional features are a convenient way to have
incremental porting efforts (not all possible features have to be ported
at once).

>
>> (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)?

As I understood, depending on the platform not all 'standard' symbols
are always in headers whose filenames are the same. But, in a given
platform, I hope there is little chance of symbol migration, hence the
test might be regarded as useless indeed. Would not be autoconf's task
to take care of that and, maybe, spare some useless tests ? Maybe
deploying headers with XXX-devel packages makes it necessary to leave
these tests though. However maybe I am wrong and/or I misunderstood your
statement. But as a developer I would like to have underlying build
layers spare me these issues, if possible.

>
> 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.
>
Well, yes, the relevant tests might be factored out in an independant m4
file. But I suppose the user program can as well, if no name collision
can occur, just include here the main Ceylan header, which itself
includes its corresponding "config.h" which contains the result of these
tests instead.

Thanks for your answer,

Olivier.