Tinny Ng wrote:
>
> So far here is what I understand from Murray's proposal:
>
> Proposed changes to be made in the Xerces-C Project
> =====================================
> 1. Xerces-C source code: all #include insides the headers (e.g. DOMParser.hpp) and
>the source files (e.g. DOMParser.cpp) will be modified with 'xercesc' added, e.g.
> #include <xercesc/dom/DOM.hpp>
> And the samples, build instruction, perl script, Makefiles, project files that part
>of the Xerces-C will all be modified together.
>
> 2. Binary distribution: include folder rename from
>$XERCESCROOT/include/<subfolders> to $XERCESCROOT/include/xercesc/<subfolders>
>
> 3. CVS tree and thus source distribution: src folder rename from
>$XERCESCROOT/src/<subfolders> to $XERCESCROOT/xercesc/<subfolders>
My understanding is that if we rename src to xercesc then there will be
no need to have an include directory.
>
> For the solution to work for ALL different builds (windows or unix build; build from
>CVS directly or build from binary distribution or build from source distribution),
>all 3 of the above must all be done,
> we cannot just do # 1 and #3 without doing #2, nor just #1 and #2 without doing #3.
I do not believe that it will be necessary to do #3 if we do #1 and #2
because the files in src will include the copied headers in
include/xercesc/.
>
> User migration required after the changes
> ============================
> 1. Either modify all the #include in the user application with 'xercesc' added
> Or modify the include search path (-I) in the Makefile or project files
> 2. And for users who build from CVS or src path directly must modify the include
>search path to change from '-I {prefix}/src' to '-I {prefix}/xercesc'
>
> But a long term recommendation is to use "#include <xercesc/parsers/DOM.hpp>" in the
>Apps
>
> Murray, please correct me if I missed anything.
>
> And so far here is what I understand about the pros and cons:
>
> Good:
> ====
> 1. It helps addressing the name collisions between header files from various
>libraries that, unfortunately(but realistically), have the same names. Different
>products (3rd party or user applications) can
> also have e.g. <util/Base64.hpp> or <util/Mutexes.hpp>. So, why not have the Xerces
>include paths start with <xercesc/...> which makes things more obvious and can help
>avoid some problems.
> 2. Besides it would make the include directory inside the distribution resemble the
>include directory created by 'make install'. Since make install is already placing
>the header files under
> <prefix>/include/xercesc/* it's silly that user apps have to reference both
>-I<prefix>/include and -I<prefix>/include/xercesc just because the header files don't
>use #include <xercesc/header.h>. Changing
> the internal #includes to <xercesc/whateverwastherebefore> would make the client
>code 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.
>
> Against:
> ======
> 1. Users migration is required. Although Murray keeps mentioning modifying Makefile
>/ Project file is not a big deal, still there is impact to user build environment and
>documentation which can be big.
> 2. Rename folder in CVS is not straight forward as outlined by Arnaud. We will
>either lose the revision history or break user CVS checkouts.
>
> Based on above summary, how about we call for vote? ALL active Xerces-C users have
>the right to vote, since this impact each and every user. +1 agree, -1 against, 0
>no comment
>
> I will start 0. I don't think it worths the effort and worths to break users'
>environment/documentation, but well, if this is something that really helps the UNIX
>users and achieve sane build behavior, I
> am not against it ... so my vote is 0.
--
Murray Cumming
www.murrayc.com
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
