Re: [BUG] after pcre.h is found, configure checks for pcre/pcre.h

[John Spencer <maillist-nmap () barfooze de>]

On 09/10/2012 09:15 PM, David Fifield wrote:

> This is a bit annoying to fix, so I think we will only do so if we get a
> patch.
>
> The problem is not this part of configure.ac, which checks for pcre.h,
> and then only checks for pcre/pcre.h if that fails:
>
> # If they didn't specify it, we try to find it
> if test $have_pcre != yes -a $requested_included_pcre != yes ; then
>    AC_CHECK_HEADER(pcre.h,
>      AC_CHECK_LIB(pcre, pcre_version, [have_pcre=yes ]),
>      [AC_CHECK_HEADER(pcre/pcre.h,
>        [AC_CHECK_LIB(pcre, pcre_version, [have_pcre=yes])]
>      )]
>    )
> fi
>
> The extra check is this one, which is done if either pcre.h or
> pcre/pcre.h is found:
>
> # We only need to check for and use this if we are NOT using included pcre
>    AC_CHECK_HEADERS(pcre/pcre.h)
>
> Notice that the first checks are done with AC_CHECK_HEADER and the
> second check is done with AC_CHECK_HEADERS. AC_CHECK_HEADERS has the
> effect of defining HAVE_PCRE_PCRE_H, which is used in a couple of places
> like nse_pcrelib.h.

why not use AC_CHECK_HEADERS for the first test then ?

but then, the real cause of this seems to be inclusion of libpcre in the 
source tree, against all good practices, just to make life simpler for 
windos folks. but can they even unpack a tar file ?
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/