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

[Yann Dirson]

On Sat, Aug 31, 2002 at 12:21:00PM +1000, Andrew Clausen wrote:
> 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?

No, I have not added any code for such things.  Probably something
should be done.


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

Cut&paste plus some (usually quite mechanical) edition.  Mostly
identifying which object class to make the function a method of (if
any), adjusting the method name and prototype, and mapping to the real
function call.


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

There are too many of them :)

> What would it look like?

There are a number of possibilities.  The easiest would be to just
keep the declarations near each other: look something like the
following (using a funnelweb-like syntax):

| @<Parted disk headers@>address@hidden
| int ped_disk_foo(PedDisk,...);
| @}
| 
| @<Parted disk swig bindings@>address@hidden
| int foo(...) { return ped_disk_foo(this,...) };
| @}

Those tools also allow to put structured internal documentation near
code blocks, so that people can think to update this at the same time.


> I've added you as a developer.

Thanks!


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

That makes sense.

Do you have a cvs history or something similar to import, or should we
just import official parted tarballs in turn ?  Note: you could
finetune a cvs repository on your disk to comfortably tune branches
and the like, and we could just move that to savannah afterward - what
do you think ?


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

I was just thinking of keeping it out of the distribution for now, but
we could do that.  As the build process of the swig wrappers is a bit
peculiar, it won't be called by default anyway.

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