Hey,

This was a really helpful email for me. I hope my reply is short and
understandable.

On 22/03/2008, Boris Kolpackov <[EMAIL PROTECTED]> wrote:

> I feel the deeper we dig, the harder it gets... Do you mean by
>  Xerces-P the whole swig/ directory or just the Perl part of it?

Ah, good question - at first I assumed moving the whole swig/
directory, but after reading your email, I can see a reason for
leaving the language independent parts and only moving the language
dependent parts out.

>  My understanding (please correct me if I am wrong) is that there
>  are two parts in the swig/ subdirectory. The language-independent
>  part (let's call it swig) that can be used to create binding for
>  other scripting languages (e.g., Python, Ruby, etc.) as well as
>  the language binding for Perl itself (after looking at the source
>  code

Yes, correct.

interfaces/ and util/ are independent and perl/ is Perl-dependent.

I was also working on a ruby/ directory (uncommitted) as a test that I
had successfully removed all Perl dependancies, but it is still not
working - because my knowledge of Ruby is not good enough yet.

>  1. If we move just the Perl part, then we can probably leave the
>    swig proper in Xerces-C++ which can be used by Xerces-P as well
>    as other language binding if they are created in the future.

Seems possible.

I favor this idea. That way, the swig/util/ directory would only get
configured in the scripting language distributions. From within the
Xerces-Perl distribution, I would run  'configure --with-swig' and
then the Makefiles for swig/ and swig/util/ would be generated.

>  2. If we move the whole thing, then the Xerces-P name is probably
>    not appropriate since, in the future, this distribution may
>    contain bindings for other languages. Perhaps a name like
>    Xerces-Scripting would be more appropriate. Yet another
>    alternative would be to have Xerces-C++, Xerces-Swig and
>    Xerces-P.

Two points: one is how the code is managed in subversion, the other
how I make a distribution tarball.

In this case I would create two different subversion modules, one is
Xerces-P, which only has the Perl bindings. The other would be
Xerces-Scripting which only contains the language independent pieces.
But this piece could be left as part of the Xerces-C subversion tree
just as easily.

To make a distribution tarball of Xerces-P, I would include both the
Xerces-C source, and the Xerces-Scripting source in the tarball -
probably using subversion's svn:external property or something.

>  Another point that I would like to make is that I don't see a
>  reason why we can't have a separate distribution (e.g., Xerces-Swig
>  or Xerces-Scripting) under the Xerces-C++ project. Before the
>  website would be a significant obstacle to this arrangement but
>  now the website is detached from the Xerces-C++ distribution
>  and can support other "sub-projects".
>
>  Any thoughts?

I would prefer to have language-specific distributions, Xerces-C,
Xerces-Perl, Xerces-Python, Xerces-Ruby, etc. As opposed to a single
Xerces-Scripting.

Sharing the website might be helpful, but that is less clear to me.

> Plus if
>  we will have a working test suite in another distribution, there is no
>  reason why we can't run it periodically and/or before the release. So
>  I don't think this should be a deciding matter.

Ah, good point. Then it seems clear to me that the Perl code belongs
back in it's own SVN tree and *not* part of the Xerces-C SVN tree.
I'll just wait for confirmation from the committers on the project and
then move it back to it's original svn tree.

Thanks for the help, jas.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to