Hi everybody, I am writing a library, called 'Ceylan', which has to be configured so that, depending on the user requests and the underlying platform, some features are activated or not. 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 (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). Doing so however defines PACKAGE, PACKAGE_BUGREPORT, PACKAGE_NAME and many other defines which clash or may clash with the ones defined by programs which are autotools-based and use my library (ex : a test program defines PACKAGE_NAME="Ceylan-test" and includes 'Ceylan.h' which in turn, thanks to 'CeylanConfig.h', defines PACKAGE_NAME="Ceylan", hence the clash). I read http://sources.redhat.com/autobook/autobook/autobook_96.html#SEC96 but was very afraid of the additional efforts and the risks ("inherently fragile" method) it would induce (I already find the porting effort to the autotools somewhat tremendous). I was thinking however to another solution that may work and be lighter : instead of |using AC_OUTPUT_COMMANDS| or *AC_CONFIG_COMMANDS* to generate a pre-cooked unconditional list of includes (thus removing the needs of exposing config.h), one may just ensure that symbols in this last file cannot clash with others. More precisely, post-processing the config file might be as simple as : cat CeylanConfig.h | sed 's|^#define |#define CEYLAN_|g' Provided that my prefix (CEYLAN_) is well chosen and that in all the Ceylan source files I use, say, "CEYLAN_HAVE_UNISTD_H" instead of HAVE_UNISTD_H", that should do the trick, isn't it ? Before doing the massive corresponding changes, I would like to know whether this solution holds, and, if yes, to share it with the poor lonesome autoconf user. Thanks in advance for any hints, regards, Olivier. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf