Murray Cumming wrote:
>
> Tinny Ng wrote:
> > 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
> > ..... ??
>
> I don't understand why these others would ever be needed. It is only
> needed for include because Xerces-C copies all its headers there to
> simulate installation of headers. If you do that then you'd better do it
> properly.
Actually, it *would* be better to just rename src to xercesc and stop
copying the headers into include.
> > 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 ...
>
> Well that's clearly silly - they should be including from a headers
> directory, and I think that they should be including installed headers.
>
> Xerces-C needs to eventually move to a sane build system, and that will
> be easier if we move towards sane build behaviour in the meantime. At
> the moment, if my app depends on Xerces-C, then it's hard to build my
> App.
>
> >
> > 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
>
> I'm not sure what that (compiling Xerces-C itself) has to do with this
> discussion. Naturally I'd fix any part of this that needed to be fixed
> as a result of changing 'cp include' to 'cp include/xercesc'.
>
> >
> > For other products like ICU, Xalan-C, they also just use $ICUROOT / $XALANCROOT
> > and don't have such addition like $ICUROOT/include/icu,
>
> Well it seems that they do things that way because they originate from
> the same team that created Xerces-C. You can't claim that you do things
> correctly just because some of your other packages do things the same
> way. The Xerces-C packaging does not compare well with other packages in
> the wider world.
>
> is it really necessary
> > for us to implement such a change which potentially breaks all users? ...
>
> As we have discussed, this will not impact users any more than any other
> Xerces-C release, because we change the library name for every release.
> I don't see how it's much different if they (foolishly) rely on
> environment variables for their paths.
>
> Deciding not to make this change would be incredibly conservative, and
> it would guarrantee that Xerces-C never moves to a standard
> autoconf/automake/libtool build system.
>
> > 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]
>
> --
> 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]
