"Daniel Stenberg" <daniel-curl_at_haxx.se> said:

> So I guess the question is: is it worth changing this to better support lcc
> builds, or can the lcc build be modified slightly to better support the
> current setup (assuming that lcc will fix this flaw at some point)?

>From libcurl's lib directory; gcc -v $(CFLAGS) base64.c:
#include "..." search starts here:
#include <...> search starts here:
 .
 ../include
 ../lib
 ../../../zlib-1.2.1
 ../../IDN/libidn-0.4.6/lib
 ../../OpenSSL-0.9.8/outinc
 g:/MingW32/include

So "../include/curl" isn't in the search path, but gcc "magically" finds
"../include/curl/easy.h" refered in "../include/curl/curl.h". gcc/cpp uses
the rule; "add the directory of current file as the 1st search directory for
#include "file". So you're right; another "easy.h" shouldn't be pixed up
from somewhere else.

I wouldn't say lcc is wrong. It just doesn't implement this magic as the
ANSI std requires (?). But it can be fixed by adding -I../include/curl/curl.

BTW. Using "-I-" with gcc (split the include path). E.g.
gcc -I- -I. -I../include, will also fail to find "curlver.h", "easy.h" etc.

Ref:
http://gcc.gnu.org/onlinedocs/gcc-3.4.0/gcc/Preprocessor-Options.html#Preprocessor%20Options

I'm not sure when "-I-" would be handy, but sure there is a use for it.

--gv
Received on 2004-06-01