On Mon, 2001-10-15 at 21:21, D. Stimits wrote:
> 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.
Please see the archive for a big discussion, vote, and test tarball
about a similar issue:
http://marc.theaimsgroup.com/?l=xerces-c-dev&m=100013310415407&w=2
and some relevant background mails:
http://marc.theaimsgroup.com/?l=xerces-c-dev&w=2&r=2&s=xercesc&q=b
Please comment on the sane_includes tarball.
--
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
