Am 24.07.2013 09:53, schrieb Daniel Pocock:
I've come across a project that is installing config.h when "make install" is invoked The project in question is the SRTP library. Some of the headers are actually dependent on some config.h stuff, for example: https://github.com/cisco/libsrtp/blob/master/crypto/include/integers.h has a lot of conditional logic The result of including that extra copy of config.h is that when I build other projects, the compiler has two copies of config.h available and complains about the redefinition of things like PACKAGE_NAME. It's quite possible that there are less obvious side-effects as well. Can anybody comment on the right way to do this? Should integers.h (above) be changed? Or should other projects using libsrtp find ways to work around this?
Apart from the fact that "config.h" should never be installed in a public location nor used in a public header file.... I would rather advise to make the file dependent on the "stdint.h" definitions. Some of the symbols do have the names of that standard header. If the library makers seeks for some compatibility with then they might want to generate a local pkg-stdint.h wrapper that adds the missing definitions - it makes clear that you want to use the compiler stdint.h whenever available with the rest being a fallback solution. Personally I had started an extra macro for that as well, see http://www.gnu.org/software/autoconf-archive/ax_create_stdint_h.html However: stdint.h is C99 and it should be superfluous to generate it. In many cases those "integers.h" are reminiscences of very old code and the best next step is to open an "enhancement request" in the bug database of the library maker: the "integers.h" should be removed and the rest of the library should include "stdint.h" directly. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
