Tinny Ng wrote:
>
> Murray,
>
> > To fix this, I'd like to add the 'xercesc/' bit to the includes in all
> > the xerces-c header. BUT, then xerces-c wouldn't build because the
> > headers are actually in src. SO, let's rename that directory. This
> > technique is used by lots of libraries, such as gtk.
>
> Sorry I couldn't quite get it.
>
> When you say "I'd like to add the 'xercesc/' bit to the includes in all the
> xerces-c header.", do you mean you want to modify the content of ALL the
> Xerces-C files to have e.g.
> #include <xercesc/dom/Dom.hpp>
> instead of
> #include <dom/Dom.hpp>
> right?
Yes.
> And you said "BUT, then xerces-c wouldn't build because the headers are
> actually in src. SO, let's rename that directory."
>
> But the xerces-c wouldn't build is not because of the name of the 'src'
> directory. It's because 'gmake Prepare' copies all the headers to
> $(XERCESCROOT)/include/{MODULE} (e.g. $(XERCESCROOT)/include/dom) instead of
> to $(XERCESCROOT)/include/xercesc/{MODULE}. And since the suffix rule in
> Makefile.incl just has
>
> -I $(XERCESCROOT)/include
>
> That's why the xerces-c wouldn't build if your change e.g.
> #include <xercesc/dom/Dom.hpp>
> is in place.
>
> So I guess the name of the src directory as "src" or "xercesc" doesn't
> matter. The change should be in "gmake Prepare" to copy headers to
> $(XERCESCROOT)/include/xercesc/{MODULE} instead of
> $(XERCESCROOT)/include/{MODULE}.
OK, I wasn't aware of that strangeness.
> But if we do that, then it also means the headers that we ship in all the
> binary package will be under e.g.
> ./xerces-c1_5_0-AIX42/include/xercesc/dom/*.hpp
>
> And as a result all user application will be broken unless they either
> change their Makefile to add
>
> -I $(XERCESCROOT)/include/xercesc
>
> or modify all their files to use
>
> #include <xercesc/dom/Dom.hpp>
>
> .... which I don't think it's a good idea ....
I don't think that it's a problem, because:
a) They should be using #include <xercesc/... - it's not clear enough
otherwise.
b) If they don't want to, they can just modify their -I argument.
c) They already need to modify their -l argument for every new release,
so it's not much more work for them.
It is necessary to do this, because 'make install' was broken for a long
time. It needs to be fixed.
> Please correct me if I wrongly interpret your motivation.
>
> Thanks!
>
> Tinny
>
> Murray Cumming wrote:
>
> > I'd like to rename the 'src' directory to 'xercesc'. Here's why:
> >
> > I recently changed the build files so that they install the headers
> > under a <prefix>/include/xercesc directory instead of polluting
> > <prefix?/include with all of the generically-named xerces-c sub dirs. I
> > had a secondary aim - to make it more obvious when client code #includes
> > xerces-c headers.
> > e.g.
> > #include <xercesc/framework/MemBufInputSource.hpp>
> > is a lot clearer than
> > #include <framework/MemBufInputSource.hpp>
> >
> > The problem is that the xerces-c header files don't use this method, so
> > you need 2 include directives when compiling your code:
> > e.g. -I/home/mcumming/include -I /home/mcumming/include/xercesc
> >
> > To fix this, I'd like to add the 'xercesc/' bit to the includes in all
> > the xerces-c header. BUT, then xerces-c wouldn't build because the
> > headers are actually in src. SO, let's rename that directory. This
> > technique is used by lots of libraries, such as gtk.
> >
> > --
> > 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]
