Re: Solving the config.h nightmare ?

[Olivier Boudeville]

Yes, I followed your advice to get rid of at least the system-specific
types in my installed headers, and it worked great.  It makes however
the code slightly more complex since for example forward-declaring
ceylan_mode_t and afterwards declaring it in the implementation file
does not seem to work with only "typedef mode_t ceylan_mode_t ;", but
the following works indeed :
struct ceylan_mode_t
{
    mode_t _mode ;
} ;
Dealing with pointers instead of instances forced me to pass references
to automatic variables as in-out parameters (i.e. 'mode_t f(x)' had to
become 'void f(x, struct ceylan_mode_t & returned)' ) but it was the
only drawback (maybe there is a simpler solution ?).

I followed as well the other advices : AX_PREFIX_CONFIG_H to have the
relevant defines prefixed, and AC_CONFIG_COMMANDS to "improve" them, so
that I get for example CEYLAN_USES_CTIME.

So, finally, everything work as wished, so thanks everybody for these
useful hints, I guess the mailing list archives will help other autoconf
learners as well in the future !

Olivier.



Daniel Reed a écrit :

> On Sat, 22 Apr 2006, Olivier Boudeville wrote:
>
>> Daniel Reed a écrit :
>>
>>> 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
>
>
> Perhaps there is some type or definition that the installer's libc's
> headers define in a historical but deprecated location. If and when
> the system operator upgrades to a libc that moves the definition to a
> "more correct" location, the results of the check that was performed
> at the install time of your software become invalid. Someone trying to
> build software based on yours might be confounded by the sudden
> breakage of your header files without any apparent change to their
> installation of your software. Something your software computed at
> install time simply became invalid. Better to have dependent software
> reperform the check at each build time.
>
> And this is probably more of an issue for dependency types from
> non-system software, where there may be less concern for -devel-file
> stability.
>
>
>>> 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.
>
>
> The issue is when these tests are performed. You perform them when
> Ceylon is installed, then you want to save the results of those tests
> in an installed header file for other software to use. I want you to
> perform the tests when Ceylon is installed and then forget their
> results, forcing dependent software to perform the same tests again
> when it (the dependent software) is built.
>
> What you are doing is essentially treating all dependent software as a
> part of your own software. You aren't a provider of an API, you are a
> code base that other people's software is integrating into rather than
> using as a consumer. The difference being that I should be able to
> compile (if not link) software to be used with your software with
> nothing more than your header files, your APIs. I may, for example,
> choose to distribute your header files with my own program, and
> instead of linking against your software at build time, perform a
> dlopen() of your library at run time to see if I can use your
> library's functionality or not. How your library was (or will be)
> built should not affect me as a consumer of your API at all. (And if
> eventual implementation details can not be isolated, then your API
> should be versioned or otherwise staticly marked so I could, for
> example, include code for all permutations of your API and still be
> able to dlopen at run time, choosing my own internal code path for the
> API version of the library that dlopen finds.)
>
> Doing so requires you to choose to use external data types, and/or
> create abstraction types around external data types, so your API does
> not change based on what other software is installed. For example, use
> a forward-declared but undefined struct pointer as a handle in .h
> files, only defining it internally (to contain whatever mode_t or
> png_header or whatever you need), then only deal with the opaque
> handle in your API.
>
>
> pthread_mutex_t *ceylon_create_mutex(void);
>
> becomes
>
> struct ceylon_thread_mutex_t;
> struct ceylon_thread_mutex_t *ceylon_create_mutex(void);
>
> You can typedef pthread_mutex_t ceylon_thread_mutex_t; in your actual
> implementation, or create it as a struct with a pthread_mutex_t
> element, or whatever, but, so long as you always refer only to
> pointers of ceylon_thread_mutex_t, and never an instance of the [fake]
> type itself, you never need to define what is in it in installable
> headers.
>