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?
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}.
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 ....
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]
