Re: Making swig bindings part of parted ? cvs tree ?

[Yann Dirson]

On Wed, Aug 28, 2002 at 09:04:19PM +1000, Andrew Clausen wrote:
> I guess it's a reasonable thing to do...

Cool !

> I should take a good look at them... in particular, how much
> maintainence would be involved, and reliability.  (Are there
> dangling-reference issues?  Regression tests?)  I should answer
> these questions myself, but feel free to save me time :)

- reliability: I consider it to be alpha quality, mostly because it has
not received thorough testing yet, not 100% of libparted is wrapped
yet, and the API of what has been wrapped may still need to change in
some places.

- maintainance: each removal from libparted API of a wrapped item will
break the wrappers (I guess that's what you mean by dangling-reference
issues ?), and each addition to the API needs to be propagated.  For
example it has taken me significant work to upgrade from 1.4 to 1.6.
Unfortunately this is not likely to be easily automated.

The solutions I can thing of to improve this (ie. keep changes in sync
automatically) would be either to add swig-specific stuff to the
parted includes directly, but that would fill them with so many ifdefs
that they become impractical for libparted maintainers, the other one
would be to use a single-source for both libparted headers and swig
interface definition, for example using a literate-programming tool.
Or just keep things the way they are and periodically check the swig
interface definition does not need upgrading.

- reliability: the scripts will call libparted through swig-generated
wrappers, so potential problems (in addition to libparted itself) can
come from bugs in swig (hopefully the swig team seems quite active
nowadays), and bugs in the interface definition, which some use of
peer-review could easily eliminate.

- there are no regression tests yet, mostly because I did not take
time to do this, and because I've not figured out how to design
regression tests on the low-level-related issues (no way I'll risk to
have a test formatting my HD :).  If this is something you already
solved, I guess this can be directly applied to the wrappers by
converting existing tests to perl/python/whatever.


> No cvs yet :(  I should do it... I'm a bit busy ATM though.  (Uni).
> You're welcome to create the CVS yourself (if you feel confident you
> can fix up any mess you might make...)

That should not be problematic :)


> If you want to, I'll give you access on savannah.gnu.org.

We can do that.  My savannah login is ydirson.


What do you think would be the best layout ?  On savannah there is
already a "standard" module named parted.  Do you think we should put
parted-swig directly inside the existing parted tree, or if not either
put parted and parted-swig in separate subdirs of this existing parted
directory (which is what the savannah team encourages), or use the
existing parted dir for parted itself, and create a parted-swig module
alongside (which is what I tend to do on my other projects) ?

Maybe it would make sense to put parted-swig in a subdir of the parted
tree, which would not be declared to automake so that it is still
exported separately for now.  That would make the transition easier if
we decide to single-source the standard headers and the swig
definitions.

Regards,
-- 
Yann Dirson <address@hidden>                 http://www.alcove.com/
Technical support manager                Responsable de l'assistance technique
Senior Free-Software Consultant          Consultant senior en Logiciels Libres
Debian developer (address@hidden)                        Développeur Debian