Removal of bindings

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Removal of bindings

Jürgen Hötzel
Hi,

I don't know why language bindings generation is part of the pacman-lib CVS
repository. Any swig-supported (not only perl/python/java) language binding
can be generated from alpm.h and a swig interface file.

Real language bindings will also ship higher level function/classes.
So i would prefer to remove automated bindings generation.

Jürgen

_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removal of bindings

Aaron Griffin
On 1/31/07, Jürgen Hötzel <[hidden email]> wrote:
> I don't know why language bindings generation is part of the pacman-lib CVS
> repository. Any swig-supported (not only perl/python/java) language binding
> can be generated from alpm.h and a swig interface file.

That's bothered me for some time as well, but I didn't put too much
thought into it.  Don't we need the alpm.i conversions, though?
Should that be distributed some way?
_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removal of bindings

Dan McGee
On 1/31/07, Aaron Griffin <[hidden email]> wrote:
> On 1/31/07, Jürgen Hötzel <[hidden email]> wrote:
> > I don't know why language bindings generation is part of the pacman-lib CVS
> > repository. Any swig-supported (not only perl/python/java) language binding
> > can be generated from alpm.h and a swig interface file.
>
> That's bothered me for some time as well, but I didn't put too much
> thought into it.  Don't we need the alpm.i conversions, though?
> Should that be distributed some way?

It doesn't look like there is whole lot in that alpm.i file at the
moment, and I'm not sure what those pointer_cast functions are doing.

Why don't we make a base-level folder named extra, write up a README
file describing the things that are in it, and put things like alpm.i
in there? Then we can simplify the building process here once at a
time. I think this will also clean up Makefile.am and configure.ac a
good amount if we get rid of the bindings always being built.

-Dan
_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removal of bindings

Jürgen Hötzel
In reply to this post by Aaron Griffin
On Wed, Jan 31, 2007 at 04:28:39PM -0600, Aaron Griffin wrote:
> On 1/31/07, Jürgen Hötzel <[hidden email]> wrote:
> > I don't know why language bindings generation is part of the pacman-lib CVS
> > repository. Any swig-supported (not only perl/python/java) language binding
> > can be generated from alpm.h and a swig interface file.
>
> That's bothered me for some time as well, but I didn't put too much
> thought into it.  Don't we need the alpm.i conversions, though?
> Should that be distributed some way?

The supplied alpm.i is just a (very simple) example about how to bind c
data types. A Real-World binding would use Type-Maps to provide smart
bindings. There is no "single" interface file to meet all needs.

Jürgen

_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev

attachment0 (196 bytes) Download Attachment