Am 25.07.2013 00:05, schrieb Peter Johansson:
On 07/24/2013 07:39 PM, LRN wrote:
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
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
