2009/10/22, Patrick Monnerat wrote:

> 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>
> >
>
> This is all right, providing the compiler understands that !
> In other words: the target OS is supposed to have an orthogonal
> directory tree structure.

Yep, certainly.

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

Ah! There's always some system that makes portability issues real fun ;-)

> 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
> :-(

It might be possible to directly attach an Apollo 11's keyboard to
program it :-D)

> 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 <>.

I can feel your pain!. No need for the docs. I suppose that more or
less all the above means that <sys/types.h>, <sys/socket.h> and
<sys/un.h> are all different MBR's of the same FILE, and that there
doesn't actually exist any MBR for any file header that would exist in
'sys', as it would actually be an MBR of a different FILE from the one
containing the three previous headers.

> 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.

I understand your reasons, trying to get rid of the leading 'curl'
path on the 'curlbuild.h' include statement in curl.h header file. And
I find them good enough to actually try to get rid of it, other OS's
without an orthogonal directory tree structure would equally benefit
from the change. Besides that if things can be simpler, they should
remain simpler.

Ok, I've done some changes and tests locally, and we can get rid of it.

The leading 'curl' path on the 'curlbuild.h' in the curl.h file,
solely exists for the benefit of configure-capable builds when done
out-of-tree. I can achieve the same result removing that leading path
and adjusting 'include' paths in some specific auto-makefiles.

I leave for you undoing whatever changes you did to adapt the OS400
package to this, once that the change is in CVS.

So now the question is...

Daniel, can this change go now into CVS or once 7.19.7 is out the door
? Not clear to me if this could be considered a fix, or simply
restoration of 7.19.0 preexisting status.

-- 
-=[Yang]=-
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html