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