Murray Cumming wrote:
>
> "Jason E. Stewart" wrote:
> >
> > "Murray Cumming" <[EMAIL PROTECTED]> writes:
> >
> > > As ususual, I'm reposting in the hope of an official reply:
> >
> > Hey Murray,
> >
> > Unfortunately, the archive doesn't provide a clear reason for doing
> > this. Could you summarize the issue again since things have changed.
>
> Yes, it does, but I'll repeat:
>
> > 1) what is broken that needs fixing
>
> It should be possible to do this:
> #include <xercesc/framework/MemBufInputSource.hpp>
> instead of just this:
> #include <framework/MemBufInputSource.hpp
>
> We would already be doing this happily if our headers were under one
> xercesc directory already.
>
> Unfortunately the coder currently requires 2 -I arguments:
> -I<prefix>/include *and* -I/<prefix>/include/xercesc, because the
> xercesc headers themselves do not mention 'xercesc' in their headers.
Also, at present, code written for a 'make install' xerces-c might not
work with a local copy of xerces-c, because the include directory in the
distribution directory is not in a xercesc directory. So that could also
be seen as something that's broken that needs to be fixed.
> > 2) how would moving the includes to include/xercesc fix it
>
> It would make the include directory inside the distribution resemble the
> include directory created by 'make install', and allow me to change the
> internal #includes to <xercesc/whateverwastherebefore>. Client code
> would then build with just -I<prefix>/include (or maybe no -I at all if
> that's the default gcc include path). Xerces-C would then seem a little
> bit more sane.
>
> >
> > 3) what are the drawbacks
>
> People may have to change their -I argument. But *every* developer has
> to change their build directives for *each* release anyway, because the
> library name changes every time. So this will not be a shock.
>
> Later, people will start to use #include <xercesc/whatever.h> instead,
> and then they can start using a future `xercesc-config --cflags` script
> or pkgconfig thingy to dynamically determine the build directives.
>
> > Thanks,
> > jas.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
> Murray Cumming
> www.murrayc.com
> [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Murray Cumming
www.murrayc.com
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
