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>
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.
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.
Tinny
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
