Yang Tse wrote:

> In addition to the fact that the documented way that apps using
libcurl must include curl's public API header files is using
preprocessor directive #include <curl/curl.h>

> Up to version 7.18.0 line #10 used word "should" from 7.19.0 onwards
line #10 uses word "must".

This is all right, providing the compiler understands that !
In other words: the target OS is supposed to have an orthogonal
directory tree structure.

OS400 do NOT have such a structure (hum... well, in fact it has one, but
it's not reachable in the compilation mode that is mostly used).
Instead, it has LIBraries as top entities, those may contain FILEs that
may contain MemBeRs. Program/header source lines can only be in MBRs;
this is the IBM "Data Management File System", full stop. No hard/soft
links. In addition, names are limited to 10 characters :-(

Thus IBM adopted several very specific (and awfull) arbitrary rules to
map an #include path to such a structure (I can send some doc to you if
you're interested in the details, but be prepared for a headache!). In
addition, the problematic path is "-delimited, not <>. These are the
reasons why I've been annoyed by this "inconsistent" include path, and
why OS400 users are advised to use the #include "curl.h" syntax.

Finally, I've resolved the problem on OS400 by updating curl.h at
install time. It works, but I'm only 50% happy with this solution. I
have to admit OS400 is a very special case.

> So my real question is if we still have to document this in some other
place to prevent this showing up each time someone which did not follow
the 10 years old suggestion gets surprised by it being a requirement
when they upgrade to the 7.19+ version.

Perhaps some lines in the FAQ... But you'll still have some puzzled
users that miss the README+code comment+FAQ !

Cheers,
Patrick
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2009-10-22