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?) 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. 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++, 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]
