<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 05/10/2009 01:28 PM, m. allan noah wrote:
<blockquote
cite="mid:97246d0e0905101128l15d1b1b0u2e3b6340dd28b7af@mail.gmail.com"
type="cite">
<pre wrap="">On Sun, May 10, 2009 at 2:22 PM, Julien BLACHE <a class="moz-txt-link-rfc2396E" href="mailto:jb@jblache.org"><jb@jblache.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Ilia Sotnikov <a class="moz-txt-link-rfc2396E" href="mailto:hostcc@gmail.com"><hostcc@gmail.com></a> wrote:
Hi,
</pre>
<blockquote type="cite">
<pre wrap="">Could you please describe in what matter using relative paths to
header files (eg. #include "../include/sane/sane.h") is better in
comparision with -I../include command line option? Just to have
cleaner picture...
</pre>
</blockquote>
<pre wrap="">This way you don't pick up installed SANE include files in the
standard include paths.
</pre>
</blockquote>
<pre wrap=""><!---->
see recent thread about freebsd build issues.
allan
</pre>
</blockquote>
<br>
A brief summary: Using #include "sane/*.h" and -I for header files that
can also be found in /usr/include is not reliable as some cpp's will
search -I paths as last option in that case; thus preferring the
/usr/include version.<br>
<br>
So this is a problem with sane/sane.h and sane/saneopts.h but I also
applied a chosen solution to all internal header files for consistency.<br>
<br>
Chris<br>
</body>
</html>