Michael Huedepohl wrote:
>
...snip...
> > > > > > > "Michael Huedepohl" <[EMAIL PROTECTED]> writes:
> > > > > > >
> > > > > > > > Well, I've analyzed the configure file and found a solution:
> > > > > > > > You only have to move the setting of prefix_include behind the check
> > > > > > > > `test "x$prefix" = xNONE && prefix=$ac_default_prefix'.
> > > > > > > > I.e., remove line 1289 and insert it after line 1376.
> > > > > > > > Here is the diff output:
> > > > > > > > diff -r1.4 configure
> > > > > > > > 1289d1288
> > > > > > > > < prefix_include=${prefix}/include/xercesc
> > > > > > > > 1376a1376
> > > > > > > > > prefix_include=${prefix}/include/xercesc
...snip...
>
> Please apply the patch as I described it above, not only adding single quotes!!!
> It's necessary to use PREFIX in upper case letters, too!
> Don't you know the patch command?
> Apply it to configure - or apply it to configure.in and use autoconf.
> If in doubt, look into Makefile.in (e.g. in the util directory)
> where prefix_include is used.
> For me, it works with and without the -P option on Linux, Solaris and FreeBSD.
>
> Michael
Ok, that definitely did the trick. Now I'm going to tempt fate once
more, and try to talk people into the wisdom of one change in packaging.
My reason for this is to bring into alignment the Windows and
non-Windows use of this package in an interchangeable way.
First, the problem description. Many people have been pointing their
packagages that depend on Xerces-c directly at the root of the Xerces-c
unpack, and not using the /usr/local/include/xerces-c/ location (this
was necessary because until now, the install was broken in
configure.in). Now that this is fixed, anyone in non-windows can simply
use include statements of this format:
#include <xercesc/DOM/whatever...>
...and then use -I/usr/local/include, or some other variation, in the
Makefile, nicely avoiding all kinds of pitfalls.
Windows authors, on the other hand, do not have an install option like
this. Windows users must still point at the root of the Xerces-c unpack
(through a project setting or environment setting), and their source
files must avoid using the "xercesc" portion of the path:
#include <DOM/whatever...>
This means a portable application must either have both projects pointed
directly at the Xerces-c source unpack, or the windows app must use a
different #include line (without "xercesc" as the prefix).
The solution to making both the source tree unpacking or the correct
install locations on non-windows useful would be to move the current
unpack tree include directory, such that:
./include/whatever...
./src/...
instead becomes:
./xercesc/whatever...
./src/...
An easier (but less direct) solution would be to unpack not just into a
versioned directory name, e.g., the current:
./xerces-c-src1_5_1/include/....
./xerces-c-src1_5_1/src/....
But instead to:
./xerces-c-src1_5_1/xercesc/include/....
./xerces-c-src1_5_1/xercesc/src/....
This latter approach would completely avoid any source file changes,
only a tarball creation would change. Windows and linux/UNIX people
could then both use format of #include <xercesc/...> consistently,
without special installation steps or conditionals.
D. Stimits, [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
