Re: [ANN] LuaNativeObjects a C bindings generator with FFI support

[CrazyButcher <crazybutcher@...>]

Hi Robert,
I tried to make the zeromq bindings on windows with vc2008 and that
combo currently doesn't work with the automatic ways:
cmake won't find libzmq (how does one tell it?), and same applies to
luarocks (although I can easily throw zmq into lua lib/include dir)

one issue related to the binding generator, vc doesn't like multi-line
strings with \, one can relatively quickly hit a limit and get an
error,
instead use
const char* somestring = "line1"
"line2"
"line3";

and compiler will make a single string out of it without complaining.
There were some other issues when I tried to compile lua-zmq with
vc2008, will let you know once resolved.

2011/3/3 David Manura <dm.lua@math2.org>:
> On Mon, Feb 28, 2011 at 5:39 AM, Robert G. Jakabosky
> <bobby@sharedrealm.com> wrote:
>> On Saturday 26, David Manura wrote:
>>>   m.constructor {name='newTrueColor', callstyle='ccall', ret='gdImage
>>> *', symbol='gdImageCreate', parameters={ "int", "sx", "int", "sy" }}
>>>   m.constructor[[newTrueColor ccall gdImage * gdImageCreate(int sx,
>>> int sy)]] -- possibly with shorthand too
>>>   if condition then -- the imperative style permits control structures
>>>     m.destructor {.....}
>>>   end
>>
>> I don't see how that first "m.constructor.." line is any easier to read/write.
>
> The second (pure data version) below is not easier to write but is
> kind-of more straightforward to interpret, manipulate, and perhaps
> debug, so it's just something to thing about:
>
>  constructor "newTrueColor" {
>     c_call "gdImage *" "gdImageCreateTrueColor" { "int", "sx", "int", "sy" }
>  },  --[A]
>
>   m.constructor {name='newTrueColor', callstyle='ccall', ret='gdImage
> *', symbol='gdImageCreate', parameters={ "int", "sx", "int", "sy" }}
> --[B]
>
>> Also for the second one, how would you handle a block of custom C code for
>> binding a complex C function that doesn't have a simple parameter types? or
>> output parameter? or object ownership transfer?
>
> Such short-hand syntax need not necessarily be usable in all
> scenarios.  You may even think of the above [A] as a short-hand for
> [B], except that [A] could be shorter.
>
>