I'm sending this to the dev list rather than posting to the bug since these comments are now off-topic for the bug.
Regarding my statements about the local (to the Middle Tennessee, USA) webdev community having the perception of Xerces/Xalan as being a difficult suite to build: I think it's largely a matter of dependencies. Most people I know using this suite use Perl. So, for the full suite, the requirements are: Xerces C++ Xerces Perl Xalan C++ XML::Xalan (since there is not an official Xalan Perl project as part of the Apache XML project) It's currently impossible to use current stable distributions of the individual packages because of the interdependencies. Xerces Perl stable is 2.0.0-3, which requires Xerces C++ 2.0.0. XML::Xalan, currently at 0.44, ostensibly requires Xalan C++ 1.3, but Xalan C++ 1.3 was not compatible with gcc-3.2.x, which has become the standard compiler for several popular Linux distros in their latest releases. For instance, I was unable to get Xalan C++ 1.3 built because of compiler issues, so I went ahead and built Xalan C++ 1.4 and managed to get XML::Xalan working with it. Now that I've gotten more familiar with the code and the build process, I might try to go back and get Xalan C++ 1.3 working because I had to do some things to XML::Xalan that make me a bit nervous (i.e., removing references to undefined functions) in order to get it to build against Xalan C++ 1.4. But, since the build documentation for both Xerces C++ and Xalan C++ is somewhat sparse, especially considering that the runConfigure shipped with the various distributions is broken on some Linux distributions, building is not as simple as the GNU-style process of configure make make install Now, I don't know whether the policy of the Apache XML project is to revise older releases to include build fixes (e.g., releasing Xalan C++ 1.3.1 such that it would work out of the box with gcc-3.2.2) or whether the project is in purely a forward momentum development cycle. Already, it seems as though development of XML::Xalan has stalled, and Jason Stewart has mentioned that more volunteers are needed for the maintenances of Xerces Perl. The key point is the number of interdependencies among four packages progressing at different rates and with different amounts of support from the development community. Please keep in mind that these are not complaints, merely observations. I'm well aware that I have the ability to improve the project(s) via personal contributions, and I hope to be able to do so, at some point. I'm just replying with some concrete examples I've experienced and had that experience shared. -tfo On Fri, Apr 04, 2003 at 04:54:33PM -0000, [EMAIL PROTECTED] wrote: > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT > <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18675>. > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND > INSERTED IN THE BUG DATABASE. > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18675 > > clean up getopt(s) section of runConfigure > > ------- Additional Comments From [EMAIL PROTECTED] 2003-04-04 16:54 ------- > I'm seeing the following, in the current release candidate build: > > # Get the command line parameters > if test -x /usr/bin/getopt; then > set -- `getopt C:p:c:x:dm:n:t:r:b:l:z:h $*` > else > set -- `getopts C:p:c:x:dm:n:t:r:b:l:z:h $*` > fi > > So C is processed. I agree we should get rid of those things that are not > supported. > > You state: > > "Among the web development community local to me, Xerces/Xalan have a > reputation for being difficult to build (especially when trying to build the > corresponding Perl modules)." > > If this is do, concrete feedback would be great, because we cannot fix what we > don't know is broken.
