Murray Cumming wrote:
>
> 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.
This tarball does what is required for portability in terms of providing
a "xercesc" prefix to include files, regardless of whether it is via
install or directly pointing at the source. It does, however, make other
directory changes which are not necessary. For those testing, it still
has the default install prefix bug, the toplevel configure.in line:
prefix_include=${prefix}/include/xercesc
Should be edited to be:
prefix_include='${PREFIX}/include/xercesc'
Now I don't know if this was only intended as a partial install sample,
but it also dies later (my unpack directory was
/home/home1/stimits/tmp9/) with this at install:
cp -fp
/home/home1/stimits/tmp9/xercesc_sane_includes/lib/libxerces-c1_5_1.so
/usr/local/lib
cp: cannot stat
`/home/home1/stimits/tmp9/xercesc_sane_includes/lib/libxerces-c1_5_1.so':
No such file or directory
make[1]: [install] Error 1 (ignored)
make[1]: Leaving directory
`/home/home1/stimits/tmp9/xercesc_sane_includes/obj'
If the entire tarball had unpacked into a directory of pseudo-format
"version-dependent/xercesc/the_rest_of_what_it_already_is/", then no
source code would require modification, and the same results would be
achieved. For reference the current pseudo-code-directory-tree is
"version-dependent/the_rest_of_what_it_already_is".
Now I noticed someone saying any changes would break their long-standing
project configurations (which dealt with problematic Xerces-c
structure), but a simple packaging scheme to have "xercesc" in the
unpack would avoid that breakage, and still give a portable directory
tree for both win and non-win users. The thing is that everyone (well,
of the projects I've seen) seems to be pointing directly at xerces
source now, rather than say /usr/local/include/, and skipping the naming
of "xercesc" stem for the include path, which is bad. But that is also
incorrect, it's better to have a modular structure to avoid future
compatibility and hack problems. The sane includes would not be a
problem for me, but I think it is a bit invasive. There are a lot of
ways it could be fixed to be uniform on both windows and non-windows,
having that extra subdirectory in unpacking just seems to be least
invasive.
D. Stimits, [EMAIL PROTECTED]
>
> --
> Murray Cumming
> [EMAIL PROTECTED]
> www.murrayc.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
