Hi Jeroen,
No disagreements here with your additional points about the benefits of
documentation. Indeed, maybe it's time for me to write some more; it'd be
a nice change from coding actually. :)
Your resolver work piques my curiosity: are you planning to opensource
your implementation once your done? Might make a nice additional component
for Xerces-C if we could figure out a way to build it as an optional,
separate DLL. Thoughts?
Cheers!
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
"Jeroen N.
Witmond" To: [EMAIL PROTECTED]
<[EMAIL PROTECTED]> cc:
Subject: Re: Installation instruction
requests
12/14/2003 08:10
AM
Please respond to
xerces-c-dev
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
