I am proposing that Xalan follow Xerces, and many other projects, and
restructure to enable proper support for "sane includes". I am looking
for approval to implement, test and contribute this change to Xalan.
Why?
Currently users have two options if they want to place the Xalan headers in
a standard location (e.g. /usr/local/include)
(A) Copy the Xalan subdirectories under xml-xalan/c/src to the include
directory. This has the negative effect of polluting the include
directory, especially since some of the Xalan directories have generic
names (e.g. PlatformSupport).
(B) Create a "xalanc" directory to contains the source subdirectories.
Besides containing the Xalan subdirectories, it also makes user code
clearer.
E.g: "#include <xalanc/XPath/XObject.hpp>" versus original
"#include <XPath/XObject.hpp>.
The problem with option (B), is that the Xalan header files do not use this
method, so when compiling 2 include directives are required.
E.g: -I/usr/local/include -I/usr/local/include/xalanc
To free users from having to specify the second directive, we should
configure the Xalan header files to be aware of the "xalanc" directory.
How?
To do this, I propose we follow Xerces and insert a 'xalanc' directory
between xml-xalan/c/src and its subdirectories in the repository. The
Makefile and each header file would have to be configured to look in
"#include <xalan/.../....>".
Xerces moved to this structure a couple of years ago. Murry Cumming who
drove this change in that project. (original post:
http://marc.theaimsgroup.com/?l=xerces-c-dev&m=99442706532719&w=2).
Based on that discussion, her is a summary of the concerns:
* This is not a functional change, but it will bring Xalan in line with
other projects and make it easier to install/use in UNIX-type environments.
* Existing user code does not have to be changed. Using both include path
options in (B) will allow existing code to compile. Changing
Makefiles/build scripts to accmodate this change should be minor, as each
release requires users to change the Xalan library name to link anway.
* Window's Visual Studio projects need to be updated, as well the
documentation.
* This change goes needs to be coordinated with the on-going effort to
improve the build/make/install of Xalan.
* The main drawback is that within CVS, historical information related to
the source files would no longer be directly accessible because the
location of the files in the repository would change.
I have also posted this message to xalan-dev list.
-Matt.
Matthew Hoyt
IBM Toronto Lab
email: [EMAIL PROTECTED]
phone: 905 413 3076
