On Sun, 30 May 2004, Gisle Vanem wrote:

> There are more problems with lcc-win32 regarding this. Is there any reason
> why <curl/curl.h> says #include "easy.h" etc. and not #include
> <curl/easy.h>. The latter is nice in that it protects against accidently
> including "easy.h" from somewhere else.

I'd say it is the opposite!

First, not dealing with this is an ANSI C violation. (I don't have a spec
handy to look this up, but I'm quite sure of this.) Also, the fact that a fair
amount of compilers already use this fine is an indication that lcc is
wrong...

Since include "easy.h" can't be made to accidentally load a easy.h from
another version's path, it will _always_ try the current dir first and in the
curl/ include path there is one present! I can't see how this causes problems
to anyone.

I prefer quotes when we include files within the curl/ dir, as then the header
files themselves don't require a modified include path, allowing constructs
like this:

#include "/usr/local/include/curl/curl.h" /* no -I used */

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)?

-- 
     Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
      Dedicated custom curl help for hire: http://haxx.se/curl.html