Hi Jan,
On 03/18/2013 07:35 AM, Jan van Dijk wrote:
It will also make the scripts less
robust.
Am I overlooking something? Is there a technical reason why that information
cannot be.communicated to the user?
It is not known where the header file is. The configure script tests if
code which contains "#include <header.h>" compiles. If it compiles it
proves that 'header.h' exist but not *where*.
I have a similar situation in one my projects in which we use a header
file "bam.h" which is either installed in '<prefix>/include/', in
'<prefix>/include/bam/' or in '<prefix>/include/samtools'. We solve it
by having
found_bam_header=no
AC_CHECK_HEADERS([bam/bam.h bam.h samtools/bam.h],
[found_bam_header=yes; break])
in configure.ac which will AC_DEFINE HAVE_BAM_BAM_H, HAVE_BAM_H,
HAVE_SAMTOOLS_BAM_H or neither. If header is not found shell variable
found_bam_header equals "no" and one can error out based on that.
Then in you can include appropriately with something like
#if HAVE_BAM_BAM_H
#include <bam/bam.h>
#elif HAVE_BAM_H
#include <bam.h>
#elif
#include <samtools/bam.h>
#endif
or you can create a convenience header that use similar logic to #define
a macro BAM_HEADER and then have
#include "convenience.h"
#include BAM_HEADER
Hope that helps.
Peter
If not, I suppose I could file a feature
request.
Thanks again, Jan.
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
