Tinny Ng wrote:
>
> ------------------------------------------------------------------------
>
> Subject: Re: Changing include to include/xercesc
> Date: Thu, 09 Aug 2001 08:01:07 -0700
> From: Tinny Ng <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Organization: IBM Toronto Laboratory
> To: [EMAIL PROTECTED]
> References: <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
><[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
><[EMAIL PROTECTED]>
>
> 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.
> 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]
