On Mon, 2001-10-15 at 23:51, D. Stimits wrote:
> 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.
Such as?
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'
I can't reproduce that problem. Could you investigate?
>
>
> 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".
I really have no idea what you're talking about. Could you try to
explain more concisely?
> 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]
>
--
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
