Hi Neil, > > Hi Joanne, > >> 1. the options should be documented better (just extract some >> information already buried in the runConfigure script and >> add it to the web page) > > Valid point. One of the (arguably rather few) nice things about > documentation is that, in opensource at least, it's a nice place where > people who don't want to/can't become familiar with the codebase can still > contribute. That is to say: If you were to offer a patch, it would > probably get applied after not too much time. >
Just for the record, two of the more important "nice things" about documentation are: - It lowers the hurdle everybody has to take when starting to use any new tool, including Xerces. In other words, good documentation may well result in more users. - It should reduce the number of simple questions on this mailing list, resulting in leaving more time to develop Xerces and/or leaving fewer questions going unanswered. This also may well result in more users. >> 2. it should be possible to reorganize this (configure.in? >> Makefile.in? I wish I knew enough about this stuff to make >> more constructive suggestions, but I don't) somehow so that >> invoking runConfigure with a very modest set of options doesn't >> result in a rather complex invocation of configure. Other >> packages I've built which are more complicated than Xerces >> manage very nicely without an extra layer of scripting. > > I'd agree with this in principle too. But bear in mind that Xerces-C has > been around for a while (four years in its opensource incarnation) and has > a lot of legacies. That means lots of people have written lots of code > around what's there, and that includes the build system. So if someone > were to go down this path, it would need to be done in such a way that we > carried along our legacy build system long enough for people to > acclimatize > to the new, better, way of doing things. > Complete agreement. Changing the build system cannot be done in a 'Big Bang'. But on the other hand, something needs to be done about it, given the number of questions and bugs it raises. In a sense, I am already working on this problem; that is, I am getting acquainted with automake et al by incorporating it in a library I am working on. (I am rewriting the Resolver by Norman Walsh http://xml.apache.org/commons/components/resolver/index.html for Xerces-C++, which could be used to fix http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12277 ) When I am up to speed on automake for that library, I will try to get Xerces-C++ to work with automake on my system. Once that is done (which may take months), I will get back to you on this point. Kind regards, Jeroen. > Cheers, > Neil > Neil Graham > XML Parser Development > IBM Toronto Lab > Phone: 905-413-3519, T/L 969-3519 > E-mail: [EMAIL PROTECTED] > > > > > > Joanne Bogart > <[EMAIL PROTECTED] To: > [EMAIL PROTECTED] > d.EDU> cc: > Subject: Re: Installation > instruction requests > 12/12/2003 07:40 > PM > Please respond to > xerces-c-dev > > > > > > > That's what I did (used the runConfigure script) after I saw all > the macros and what-not it defined, and it worked all right > for my simple case, but I still think > > 1. the options should be documented better (just extract some > information already buried in the runConfigure script and > add it to the web page) > 2. it should be possible to reorganize this (configure.in? > Makefile.in? I wish I knew enough about this stuff to make > more constructive suggestions, but I don't) somehow so that > invoking runConfigure with a very modest set of options doesn't > result in a rather complex invocation of configure. Other > packages I've built which are more complicated than Xerces > manage very nicely without an extra layer of scripting. > > Joanne > > Radovan Chytracek wrote: > >>Hi, >> >>you should run the "runConfigure" script instead of 'configure'. All >>runConfigure options are available as shown on Xerces-C web pages: >> >>runConfigure: Helper script to run "configure" for one of the supported >>platforms >>Usage: runConfigure "options" >> where options may be any of the following: >> -p <platform> (accepts 'aix', 'linux', 'freebsd', 'solaris', >> 'hp-10', 'hp-11', 'openserver', 'unixware', 'os400', 'irix', >> 'ptx', 'tru64', 'macosx') >> -c <C compiler name> (e.g. gcc, cc, xlc_r, icc or ecc) >> -x <C++ compiler name> (e.g. g++, CC, xlC_r, icc or ecc) >> -d (specifies that you want to build debug version) >> -m <message loader> can be 'inmem', 'icu', 'MsgFile' or 'iconv' >> -n <net accessor> can be 'fileonly', 'libwww', 'socket' or >> 'native' >> -t <transcoder> can be 'icu', 'Iconv400', 'Iconv390', >> 'Uniconv390', >>'IconvFBSD' or 'native' >> -r <thread option> can be 'pthread' or 'dce' (AIX, HP-11, and >>Solaris) or 'sproc' (IRIX) or 'none' >> -b <bitsToBuild> (accepts '64', '32') >> -l <extra linker options> >> -z <extra compiler options> >> -P <install-prefix> >> -C <any one extra configure options> >> -h (get help on the above commands) >> >>This was working for me on all platforms I used to build Xerces-C from >>sources ( e.g. Cygwin/Windows, Linux, Solaris ) for final installation I >>have used the provided Perl scripts in scripts directory even on >>Windows/Win32 platform. They are fully automated inlcuding re-build from >>sources + installation into the target area. >> >>Hope this helps >> >> Cheers >> >> Radovan >> >>----- Original Message ----- >>From: "Joanne Bogart" <[EMAIL PROTECTED]> >>To: <[EMAIL PROTECTED]> >>Sent: Friday, December 12, 2003 7:47 PM >>Subject: Installation instruction requests >> >> >> >> >>>Hi. I'm in an environment (Linux, gcc compiler) where there is no >>> >>> >>advantage >> >> >>>that I can see to using the runConfigure script. The instructions > mention >>>that it is possible to use configure directly, but they give very little >>>idea of how. A single example, showing how to set one of the >>> >>> >>xerces-c-specific >> >> >>>configure options, like -n or -t, using just the configure script would >>>be very helpful. >>> >>>Even for those using runConfigure, I see no description in the build >>>instructions web page of what the effect of the different >>>settings for, say, the -n option would be, nor of what the default >>>values for the various options are. I found most of what I needed to >>>know by looking at runConfigure itself. Could the information there >>>be extracted to the web page? Also, I think it's standard practice >>>to add descriptions of package-specific options to the configure >>>script so that they are displayed with the command >>> >>> ./configure --help >>> >>>Thanks, >>> Joanne >>> >>>--- >>> >>>Joanne Bogart >>>Stanford Linear Accelerator Center >>> >>>[EMAIL PROTECTED] >>> >>> >>> > \ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
