Re: [alpine-devel] apk-tools idea: binding to other applications and languages
2010/3/2 Cameron Banta <cbanta_at_gmail.com>:
> On 03/02/2010 03:44 AM, Timo Teräs wrote:
>> Natanael Copa wrote:
>>> Som things I have been thinking of for some time.
>>> It would be nice to make apk-tools functions available from other
>>> applications and higher level languages. The immedeate need I have is
>>> a binding to the version compare functions from lua.
>> However 1&2 do require that we start to maintain some sort of
>> stable API. At least for the high level stuff the lua code wants
>> to do.
> A couple thoughts on this.
> I like how easy lua is to embed into the app itself with no external
> dependencies. Because apk is very small to start with that will add
> considerable size to the executable (100K-300K I think).
> This would allow us to write even some core functionality of apk in lua.
> I believe you can also compile lua scripts directly into the executable
> - size is bigger, but makes for easier development and changes.
> This also allows writing plugins directly in lua, and just dropping them
> in some directory to extend the functionality of apk.
I'm not sure we want pull in lua in the apk core code. I'm more
interested in having a c library with lua bindings than embedding lua
in the apk executable. (lua is good at the latter though)
> That's all a bit different than having an app use apk. I've used swig
> (http://www.swig.org/) before, and I like how it can create bindings for
> several languages (lua, python, perl, php, ruby, etc) from one swig
> config file that basically defines the API. These bindings could all be
> in their own apk packages and be depended upon by any apps that want to
> use them. These bindings can be compiled into their .so files from the
> same source files that apk is compiled from, so there wouldn't really be
> much duplication of code.
> There are other tools like swig out there, swig is just the only one
> I've personally used before.
lua bindings to c libs is pretty easy, even without swig and i think
swig gives you even more overhead.
The big thing here though is a timo say, a more or less stable api for
the library. What do we want high level langs should be able to do?
Received on Tue Mar 02 2010 - 17:32:35 UTC