I just worry, if we do this, will we eventually be asked to add "xercesc" to all
the folders
=> include/xercesc
=> samples/xercesc
=> bin/xercesc
=> lib/xercesc
=> doc/xercesc
.... ??
and for someone who uses our source package, and uses the src path as the
include path directly (e.g. I noticed xalan uses /I
"..\..\..\..\..\..\xml-xerces\c\src" as include path), then we need to further
change src to
=> src/xercesc
The ripples can be unexpected ...
And for the binary package we ship right now, we have $XERCESCROOT/ to
differentiate the product already
$XERCESCROOT/bin
$XERCESCROOT/doc
$XERCESCROOT/include
$XERCESCROOT/lib
$XERCESCROOT/samples
For other products like ICU, Xalan-C, they also just use $ICUROOT / $XALANCROOT
and don't have such addition like $ICUROOT/include/icu, is it really necessary
for us to implement such a change which potentially breaks all users? ...
Tinny
Murray Cumming wrote:
> Still waiting:
>
> Murray Cumming wrote:
> >
> > I'm still waiting on a maintainer's go-ahead on this. I'm not going to
> > do this work only to have it rejected later.
> >
> > 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.
> > >
> > > > 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]
>
> --
> Murray Cumming
> www.murrayc.com
> [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
