It's pretty easy to make it clear about includes with comments:
// Here's the xerces includes
#include ...
// Here's the abc includes
...
I guess I don't really see the problem. Subdirectory namespaces really don't
matter - it's the header files themselves. And if you have 2 headers with
the same name and you need both, you're pretty much in trouble anyways
because of things like "#ifndef AttrImpl_HEADER_GUARD_"
Dave Connet
> -----Original Message-----
> From: Peter A. Volchek [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 11, 2001 5:31 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Renaming src to xercesc
>
>
> > Here's my previous post again, for those who missed the reasoning:
> >
> > 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]
