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. 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. 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++. 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]
