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

[Andrew Clausen]

On Wed, Aug 28, 2002 at 02:25:04PM +0200, Yann Dirson wrote:
> > 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.

OK

> - 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 ?),

No.  I mean when something like _disk_push_update_mode() is called,
free-space place-holder partitions are destroyed, and recreated, etc.
libparted isn't very friendly, wrt ref-counting / gc systems.

I can't find anything that explains this well in the archives.

But, say, for example, that you ped_disk_destroy() a disk, and
you still have a reference to a partition on that disk... do your
bindings deal with this ok?

> 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.

Yeah, ok.  Is it hard work, or just cut&paste?  I guess I need to
learn SWIG.

> would be to use a single-source for both libparted headers and swig
> interface definition, for example using a literate-programming tool.

Do such tools exist?  What would it look like?

> Or just keep things the way they are and periodically check the swig
> interface definition does not need upgrading.

Sounds the easiest option.

> - 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 :)

You don't need to risk anything like that.  Parted can operate on files
containing "virtual" hard disks.

> 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.

The regression tests in libparted are pretty crappy.  I think writing
the tests on top of SWIG is the best approach anyway... it's much
more convenient to do in a scripting language like python :)

> > If you want to, I'll give you access on savannah.gnu.org.
> 
> We can do that.  My savannah login is ydirson.

I've added you as a developer.

> 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) ?

Well, we'll need a few branches... parted-1.6.x, parted-1.4.x, and
I guess a branch parted-1.6.x-swig, which would be merged some-time
into 1.6.x, I guess.

The swig bindings should probably be a sub-directory, on the same
level as "libparted", right?

> 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.

Well, automake needs to know about it, so it can do "make dist".
But, I guess compilation of swig should be disabled by default?

Cheers,
Andrew