Boris, Gareth,
I agree that the committers cannot check that the build is sane in every
component/platform; that's why we have the wiki page where we annotate
what works and what doesn't work in a bunch of platforms that we try to
test regularly. Xerces-P is currently at the same level of Win32+Borland
(someone can test it twice a year), but better than AS/400 (nobody has
an idea of where to get a machine, and how to compile on it).
Before we release a version, we try to test (and fix) as many platforms
we can, and if one of them doesn't build, it's out of the list of
supported platforms. For 3.0, Xerces-P would be in the distribution, as
Jason found the time to fix it; for 3.1, if Jason cannot do it and
nobody else stepped in to do it, it will be out of the distribution.
In the meanwhile, it would be helpful if a user could decide to download
just Xerces-C or the combination Xerces-C+Xerces-P, so that we can get
some metrics on the interests of the silent developers. This implies
that "configure" should not process makefiles in the swig directory, so
it can live without that folder in the distribution (and swig/Makefile
can avoid implementing special targets required by autoconf).
Jason, would it be possible to implement the libutil.a helper library
like you do with the libTranscoder.a, i.e. using Makefile.PL instead of
Makefile.am?
Alberto
Boris Kolpackov wrote:
Hi Gareth,
Gareth Reakes <[EMAIL PROTECTED]> writes:
1 - is anyone downloading / using P
That's not going to be easy since Xerces-P will now be part of
the Xerces-C++ distribution.
2 - is it painful for the contributors to check they have not broken
the bindings
3 - whether Jason or someone can help when there are problems
My position is the same: I don't mind having Xerces-P be part of
the distribution if we have someone to maintain it. I, however,
do not want to be forced to run extra tests every time I change
something plus learn another programming language (Perl) and
technology (swig) to fix stuff that I am not even interested in.
As I side note, I wonder how contributors who use Windows/VC++
as their development platform are going to run swig tests since,
AFAICT, swig can only be built with make.
(BTW, I don't think the argument that we already have to make sure
our changes don't break other parts of Xerces-C++ applies here. In
this case we have a whole new programming language and technology
involved).
I would therefore prefer an alternative approach:
1. The contributors don't have to make sure their changes are not
breaking swig.
2. Before the release, if something is not working in swig, we
ask all interested parties on the mailing list to fix it. If
this does not happen we move swig to the attic and release
this version without swig.
3. If at some point we get someone interested in getting swig
back into shape, we move it back from attic to trunk.
To make it clear, I don't have anything against Xerces-P or swig.
I don't particularly like how from a project that depends on
Xerces-C++ it transitioned into a project that is part of Xerces-C++
and now tries to force me to maintain it. But this decision was made
before I got involved with the project.
Boris
--
Boris Kolpackov, Code Synthesis Tools
Open source XML data binding for C++: http://codesynthesis.com/products/xsd
Mobile/embedded validating XML parsing: http://codesynthesis.com/products/xsde
---------------------------------------------------------------------
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]
