Hi, One of my library projects sets quite a few CPPFLAGS and macros in config.h, most of it is done by configure: https://svn.resiprocate.org/viewsvn/resiprocate/main/configure.ac?view=markup We've discovered that in some cases, some other projects using the headers from reSIProcate need to have some of the same CPPFLAGS and/or macros in their own config.h, e.g. https://github.com/catalinusurelu/reConServer/commit/8644e5d581c361fa5eee5f2fbf405cb3cc76f7fa What is the recommended way to do this? I don't think it is feasible for the library project to distribute config.h because things like PACKAGE_NAME would then be defined twice in some situations. Nor do I think it is reasonable for every developer of a dependent package to have to know which CPPFLAGS were used in building the library. Is it considered bad practice for the headers from the library project's public API to be dependent on config.h and/or CPPFLAGS? Should we be distributing a config script, e.g. bin/xxx-config that can emit CPPFLAGS? Regards, Daniel _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
