make install : config.h?

[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?

[LRN]

Post by 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
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?

This is wrong. No one should ever install a header named 'config.h'.

If a project must install its config.h, it should install a renamed copy
of it (or rename it altogether and use it under the new name even
internally; 'config' part of 'config.h' is not mandatory, it's just the
usual name).

Or even better, separate config.h into two files - use one internally
(normal config.h), while the other will be both installed and used
internally (sadly, i can't tell you how exactly that can be done;
config.h.in is generated by autoheader, so they will have to either
tinker with autoheader, or just form the second (smaller) header
manually, at least an .in template of it).

- --
O< ascii ribbon - stop html email! - www.asciiribbon.org

[Peter Johansson]

Post by LRN
Or even better, separate config.h into two files - use one internally
(normal config.h), while the other will be both installed and used
internally (sadly, i can't tell you how exactly that can be done;
config.h.in is generated by autoheader, so they will have to either
tinker with autoheader, or just form the second (smaller) header
manually, at least an .in template of it).

We do exactly this in yat. We create a 'yat/utility/config_public.h'
from 'yat/utility/config_public.h.in', which is then installed. For
details please see http://dev.thep.lu.se/yat/browser/trunk/configure.ac

Cheers,
Peter

[Guido Draheim]

Post by LRN
Or even better, separate config.h into two files - use one internally
(normal config.h), while the other will be both installed and used
internally (sadly, i can't tell you how exactly that can be done;
config.h.in is generated by autoheader, so they will have to either
tinker with autoheader, or just form the second (smaller) header
manually, at least an .in template of it).

We do exactly this in yat. We create a 'yat/utility/config_public.h' from 'yat/utility/config_public.h.in', which is then installed. For details please see http://dev.thep.lu.se/yat/browser/trunk/configure.ac
Cheers,
Peter

However your file does contain definitions without a prefix

http://dev.thep.lu.se/yat/browser/trunk/yat/utility/config_public.h.in

#undef HAVE_BAM_BAM_H
#undef HAVE_BAM_H
#undef HAVE_SAMTOOLS_BAM_H

So when a third project includes your config_public.h and a local
config.h .. then you would kill any "#define" of the local config.h
thereby creating some irrititating behaviour where the configure.ac
sad "bam.h found" and the #ifdef'ed section is skipped.

I'd advise strongly against installing a public header with definitions
as they are produced for a local config.h - do always use a prefix. (You
have done that for the other names in the public_config.h)

To avoid creating a pkgconfig.h.in manually, I let it be generated
automatically from the config.h by an additional autoconf macro:

http://www.gnu.org/software/autoconf-archive/ax_prefix_config_h.html

[Guido Draheim]

Post by LRN
Or even better, separate config.h into two files - use one internally
(normal config.h), while the other will be both installed and used
internally (sadly, i can't tell you how exactly that can be done;
config.h.in is generated by autoheader, so they will have to either
tinker with autoheader, or just form the second (smaller) header
manually, at least an .in template of it).

We do exactly this in yat. We create a 'yat/utility/config_public.h' from 'yat/utility/config_public.h.in', which is then installed. For details please see http://dev.thep.lu.se/yat/browser/trunk/configure.ac
Cheers,
Peter

However your file does contain definitions without a prefix

http://dev.thep.lu.se/yat/browser/trunk/yat/utility/config_public.h.in

#undef HAVE_BAM_BAM_H
#undef HAVE_BAM_H
#undef HAVE_SAMTOOLS_BAM_H

So when a third project includes your config_public.h and a local
config.h .. then you would kill any "#define" of the local config.h
thereby creating some irrititating behaviour where the configure.ac
sad "bam.h found" and the #ifdef'ed section is skipped.

I'd advise strongly against installing a public header with definitions
as they are produced for a local config.h - do always use a prefix. (You
have done that for the other names in the public_config.h)

To avoid creating a pkgconfig.h.in manually, I let it be generated
automatically from the config.h by an additional autoconf macro:

http://www.gnu.org/software/autoconf-archive/ax_prefix_config_h.html

[Peter Johansson]

Post by Guido Draheim
So when a third project includes your config_public.h and a local
config.h .. then you would kill any "#define" of the local config.h
thereby creating some irrititating behaviour where the configure.ac
sad "bam.h found" and the #ifdef'ed section is skipped.

Good point. Will try to change that, although it breaks compatibility.

Thanks,
Peter

[Guido Draheim]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by 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
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?

This is wrong. No one should ever install a header named 'config.h'.
If a project must install its config.h, it should install a renamed copy
of it (or rename it altogether and use it under the new name even
internally; 'config' part of 'config.h' is not mandatory, it's just the
usual name).

A "config.h" should not even get installed in a renamed fashion - if two
libraries have these then you will see errors coming up speaking of
"duplicate defintion"s. You will even get subtle differences in library
behaviour when the precompiler definitions in the two installed config.h have a
different value due to a different configure.ac content. I've even seen errors
when a function is defined conditionally on an environment check.

So an explicit pkgconfig.h should try to use some kind of prefix for the
definitions so that you would not try to depend a precompiler-if on the config
value of another project. To make it easier I had written a macro for it that
will take the config.h creating a pkgconfig.h by adding the library name as
a proper prefix, see:

http://www.gnu.org/software/autoconf-archive/ax_prefix_config_h.html

Or even better, separate config.h into two files - use one internally
(normal config.h), while the other will be both installed and used
internally (sadly, i can't tell you how exactly that can be done;
config.h.in is generated by autoheader, so they will have to either
tinker with autoheader, or just form the second (smaller) header
manually, at least an .in template of it).
- --
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
iQEcBAEBAgAGBQJR76C3AAoJEOs4Jb6SI2CwbfcIAM4p8Og/fQLLc39nkS5GClFa
j0mJuZOlnFql/Al9oLSZ1O+imfuxqgJ1rmS4InlHmTMMxeWRzvbH2REwMXkIL+Rh
tnE+AgU3JcXjMAYKg/OrGmNZUn8cLosDqe/R149uHgSVRZyKdaygdVoW3q4dc1JI
0Wkhjhp7Rz7qgYhgxBUOnvB7WW4Lb5E3JtWdPuWaWShnA8BeIbKRlnSmqTwLUZ5y
MkN+7umbaqBHUMeSO9Xw2kr0F5Tc85ALw8K7mkOCIvGI4e8GxbcVVxAlR8KshTO5
uVuWpeunoFxivhN17AFW3JNDf6xKBCJrdPthJv/qdo5jCwM7NgWN3YbeRM0N/w0=
=d7+f
-----END PGP SIGNATURE-----
_______________________________________________
Autoconf mailing list
https://lists.gnu.org/mailman/listinfo/autoconf

[Guido Draheim]

Post by 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
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.