> Murray Cumming wrote: > > > > On Thu, 2001-10-11 at 01:01, D. Stimits wrote: > > > Murray Cumming wrote: > > > > > > > > On Thu, 2001-10-11 at 00:02, D. Stimits wrote: > > > > > Murray Cumming wrote: > > > > > > > > > > > > On Wed, 2001-10-10 at 19:02, D. Stimits wrote: > > > > > > > Where would I post, or ask for changes to the official Xerces > > > > > > > distribution? > > > > > > > > > > > > Erm, this list, of course. > > > > > > > > > > > > Right now, the immediate change (and I can provide > > > > > > > Makefile patches if desired) would be that make install fails to place > > > > > > > headers for devel in any conventional location, > > > > > > > > > > > > Since Xerces-C 1.5.1, the headers have gone into <prefix>/include. > > > > > > What's wrong with that? > > > > > > > > > > Well, in general, "include" is a _really bad_ (did I mention "really > > > > > really" bad also?) > > > > > > > > Sorry, I mean that since 1.5.1 the headers have gone into > > > > <prefix>/include/xercesc. There is no problem with where the headers are > > > > installed. > > > > > > This is good. I'm using 1.5.1 though, and headers are not being > > > installed at all during make install. > > > > First you say that they are installed to 'random' locations, then you > > say that they are not installed at all. I'm sure that it's working for > > me. I personally changed the headers install path from <prefix>/include > > to <prefix>/include/xercesc so I know that there stuff in there to > > install the headers. > > "random" is not meant in the mathematical sense. What it means is that > wherever xerces is unpacked, there will be an include subdirectory to > that, and this is the final resting place. It's up to the whims of where > it is unpacked. This isn't a result of install. Install does not install > any headers, all headers remain within the tarball unpack. I've run the > install from two different unpackings in two different locations, it has > always added the lib file, but never headers outside of the unpack tree. > > > > > It's not that complex, so I suggest that you try to find out what's > > wrong. > > This is why I'm trying to see what is going wrong with headers not > installing. Again, unpacking the source appears to be the only location > the headers exist. make install does not provide headers outside of the > source tree. Before you do any testing, make sure you unset all > environment variables that have anything to do with Xerces, and see how > it does things completely fresh. Move your existing install headers and > libs elsewhere temporarily. One note here is that since the lib file > does in fact go to /usr/local/lib/, I have to conclude that "prefix" is > set to /usr/local, and thus if things are as you say, then headers must > exist in /usr/local/include/xercesc/ after install. The headers remain > missing. For reference, I'm doing this on Redhat 7.1 linux. I see that > documentation only shows it checked to Redhat 6.1, which is > extraordinarily out of date; perhaps changes in the environment mean it > no longer behaves as it did a couple years back under 6.1.What environment variables have anything to do with Xercec-C++ apart from XERCESCROOT? And that NEEDS to be set.
Will you please just investigate the problem, instead of wasting all your time with these verbose emails? I have obviously already tested it to my satisfaction (on various versions of Redhat (including 7.1) and Solaris)
> > D. Stimits, [EMAIL PROTECTED] > > > > > It sounds like there should be a > > > /usr/local/include/xercesc/ after root does the install process, but it > > > is missing. Is it possible that this broke some time back, but since the > > > files were already in place for developers, nobody noticed it? > > > > > > > > > > > forced include path. It can cause all kinds of > > > > > namespace collisions, it should instead be representative of a specific > > > > > vendor or package...a unique identifier. E.G., > > > > > <prefix>/include/xerces-c/ or <prefix>/include/apache-xml/, > > > > > <prefix>/include/xerces-j/, so on. > > > > > > > > > > Next, I have not found any sane defaults for "prefix". If unspecified, > > > > > usually /usr/local/ would be desirable. > > > > > > > > It does default to a prefix of /usr/local. Please give us specific > > > > information if you have found a bug. > > > > > > Nothing is being installed to /usr/local/, aside from actual libraries > > > in /usr/local/lib/. Nada. Since the other package I need most urgently > > > came out when 1.4 was used, and it had to hack include paths with hand > > > edited values, I assume the lack of headers existed then as well, but I > > > can't confirm it. If I have done something incorrect that would cause > > > install of libs but not headers, then there is a flaw in configuration > > > instructions. > > > > > > > > > > > An install without specifying > > > > > alternate prefix would result in /usr/local/include/xerces-c/ (as one > > > > > possible example). Non-programmers, maybe basic administrators, can be > > > > > expected to install this software as a step in installation of other > > > > > packages...using /usr/local/ as a default prefix, and having any > > > > > installed headers that might collide with other projects separated by a > > > > > good subdirectory name can save much grief, while simultaneously > > > > > allowing non-programmers to survive the install with all their hair > > > > > (assuming they started with hair). Simple things like this can cause > > > > > packages to be abandoned by the non-savvy. > > > > > > > > > > On the UNIX-flavor systems, which looks like this covers everything > > > > > runConfigure is used for, failure to specify C and C++ compilers should > > > > > end up with default values of gcc and g++, > > > > > > > > I'm pretty sure that recent version do default to g++. I am increasingly > > > > convinced that you're using an old version of Xerces-C++. > > > > > > This may be so, but runConfigure spits this out as an error. Perhaps it > > > uses g++ if nothing was specified, but the script fails to properly > > > detect this. If you have an environment variable set, this would mask > > > the problem. > > > > > > D. Stimits, [EMAIL PROTECTED] > > > > > > > > > > > rather than simply > > > > > dying...these compilers are just too common (and quite good) on a huge > > > > > assortment of UNIX flavor systems. I imagine that Apache and Xerces are > > > > > most tested under gcc and g++ as well...should those not be valid > > > > > compilers, it will be obvious; alternately, it is possible (without > > > > > special tools) to test for the existence of programs such as "cc", > > > > > "gcc", "c++", or "g++", in a case where the person installing fails to > > > > > specify values. Currently, without specification, I see this (1.5.1): > > > > > I do not recognize the C++ compiler ''. Continuing anyway ... > > > > > ./runConfigure: [: too many arguments > > > > > > > > > > These are all simple things would could go a long way towards allowing > > > > > development of packages that work with Xerces-c, and allow average > > > > > people to compile all packages without excessive efforts. Right now I'm > > > > > finding that one package I'm trying to work with has gone through a few > > > > > hacks in anticipation of normal users failing to figure out Xerces-c; > > > > > even with those hacks, one has to manually edit the other package's > > > > > Makefile to figure out how to get the two to cooperate. From a coding > > > > > perspective, there are "little things" that could make a major > > > > > difference in product success (where the product must be compiled, and > > > > > is not distributed in binary format). > > > > > > > > > > D. Stimits, [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > and anything depending > > > > > > > on Xerces ends up hard coding include paths to a tarball unpack of > > > > > > > Xerces. For example, and this could be relocateable, make install should > > > > > > > also install headers at /usr/include/xerces/ or > > > > > > > /usr/local/include/xerces/ on Linux (and variations for most UNIX > > > > > > > flavors). Is it possible to communicate with official developers > > > > > > > concerning configuration and packaging issues? Is there a more active > > > > > > > mailing list for such things? > > > > > > > > > > > > > > D. Stimits, [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] > > > > > > > > > -- > > > > Murray Cumming > > > > [EMAIL PROTECTED] > > > > www.murrayc.com > > > > > > --------------------------------------------------------------------- > > > 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] >
-- Murray Cumming [EMAIL PROTECTED] www.murrayc.com |
