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. It's not that complex, so I suggest that you try to find out what's wrong. 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]
