Murray Cumming wrote:
>
> On Mon, 2001-10-15 at 23:51, D. Stimits wrote:
...snip...
> > >
> > > 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?
The 1.5.1 tarball unpacks with a scheme where the toplevel configure.in
is at:
./src/configure.in
(and includes at ./include/DOM/ and family)
The sane includes unpacks such that "src" is renamed "xercesc". While
consistent with the project name, it isn't necessary to change the "src"
subdirectory. It's possible it might have some aesthetic appeal, but I'd
personally stick to "src".
>
> 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?
Ahh, the great bane of configuration pain. I'll try to find out, but I
can't promise I'll succeed. I did add the patch to the toplevel
configure.in to produce:
prefix_include='${PREFIX}/include/xercesc'
(adds quotes, and capitalizes PREFIX)
Without that, the headers don't install. Possibly this also caused
something else to break. I'll see if I can figure it out over the
weekend.
>
> >
> >
> > 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?
Yes, I see a flaw in my argument (the paragraph above that says "src"
doesn't need to be renamed still applies though). More change would be
required than a simple repackaging. But perhaps a description of the
goal would help, forgive my repetition about to show up, I'd like to
have the problem statement available here.
On every UNIX/Linux system that the header install bug is fixed on,
regardless of whether a default prefix is used, or a custom prefix, the
headers will be available on a path with this:
..../include/xercesc/....
For example, somewhere on the system will be:
..../include/xercesc/dom/DOM_Attr.hpp
The "...." could be /usr/local, it could be /usr, it might be
~/myheaders. No matter what that prefix is, one can include DOM_Attr.hpp
via:
#include <xercesc/dom/DOM_Attr.hpp>
(and also adding a '-I${prefix}/include' to the compile line...changing
this will allow relocation of the headers anywhere wilthout altering the
include statement itself, and without using a quoted and inflexible
format, e.g., without "#include
"../../xercesc1_5_1/include/dom/DOM_Attrib.hpp")
Unfortunately, windows is a somewhat sucky development environment, it
does not have the concept of a system header directory or standard build
filesystem hierarchy. One does not install Xerces-c headers to a known
location. Instead the source is unpacked, then you either point an
environment variable at it, or adjust a project file. Fine, it's part of
life. But since the unpacked source does not currently follow the same
directory tree that a UNIX/Linux install would point at, include
DOM_Attrib.hpp would require a different include line:
#include <dom/DOM_Attrib.hpp>
Versus:
#include <xercesc/dom/DOM_Attrib.hpp>
Possibly one could get around that with #ifdef __win32__, but that's
ugly. Solution 1 would be for the developer on win32 to manually copy
the include source so that it is in "include/xercesc/" instead of
"include/" somewhere else. Solution 2 would be preferable, that Xerces-c
unpacks directly to a structure of "include/xercesc/". It saves either
condition includes or manual directory copying.
The only change that is needed to the current Xerces-c source structure
to make this work is that the include directory not directly contain
"dom", "framework", "idom", and so on, but that it contain "xercesc" and
that in turn "xercesc" contains those other directories. If the current
"src" subdirectory is to be renamed, fine, but I am saying that it is
not necessary. The xercesc_sane_includes changes the include directory
correctly, it is a needed change, other changes are not needed.
D. Stimits, [EMAIL PROTECTED]
>
> > 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
