Re: [Wxlua-users] genwxbind.bat

[John L. <jla...@gm...>]

On 12/21/05, k. holwerda <kla...@nl...> wrote:
> Trying to make a start here for external programs.
> Read in the docs directory building.txt, arrived at the line:
>
> If you wish to use the build files for modlues/wxbind that exist in wxLua
> for your own project along with your own wxluasetup.h you need to...
>
> ;-))

Heh, that should be finished.

> So let me see.
> WXLUASETUP_DIR has made it, so setting the include path to my own
> luasetup.h is fine.
>
> What i am puzzled with is the generation of bindings.
> Am i right that those binding are now platform and settings independent,
> in can be in principle become part of the wxLua distribution?

Yes, there is one last issue of the static int variables used as the
tags for lua userdata types. These variables are shared among all off
the lua states created and the names of them need to be known if you
wish to get a variable from lua to C++. I have been thinking about
just using a hashtable for them, but I cannot decide. Currently you
must always add bindings to wxLua in the same order, which is done by
default, but things will break if you change the order or remove one.

> Meaning i do not have to generate those in the future and they have no
> relation with my own bindings?

Right, they are only for wxWidgets and eventually wxLua will compile
without them at all. Though, in that case you don't get any wxWidgets
functionality in lua, but you do get a C++ interface for lua.

> And if i only want part of the wxLua bindings, this is just a matter of
> changing my own luasetup.h and rebuild the wxlua library?

Yep, hopefully.

> I assume genwxbind.bat can be used for my own wxart2d.rules file.
> My wxart2.rules file contains this at the top, but i wonder if this is
> needed?
> wxlua_dir =3D  os.getenv("WXLUA")

If you like, it's up to you how you implement it. I've attached a
rules file I use for a program of mine. You can compare it with the
one in wxLua for the wxWidgets bindings, bindings/wxwidgets/wx.rules.

> But reading this in wx.rules, i get the feeling that i need to change
> more, in order to
> get my own binding in the right place, assuming there is no need to have
> them in the same place as the wxWidget bindings.

You'll want to put them in your own dir. I have made the bindings
completely insulated as a library with no need for any external header
files. Everything works by adding new bindings to a static member
variable of the wxLuaBinding class. You can compile your bindings
however you want, as a separate library or together with your program
as object files. Just make sure that you link to your library after
linking to wxLua.

> In other words i will get a seperate library for my own bindings, next
> to the one containing the wxWidget bindings.
> Something like:
>
> wxart2d_dir =3D  os.getenv("WXART2D")
>
> interface_dir     =3D wxart2d_dir.."/bindings"
> output_dir        =3D wxart2d_dir.."/src"
> output_header_dir =3D wxart2d_dir.."/include"
>
> And in the
>
> interfaceFileList =3D
> {
>     wxart2d.i
> }
>
> This seems to work, many things are generated, and they contain things
> related to what is in wxart2d.i ;-)
>
> What should i do with the next, should i call it wxart2d? Is that oke/wis=
e?:
>
> hook_namespace       =3D "wx"

I am unsure about this. I have not actually tested what happens if you
try to put two bindings into the same namespace. Maybe it works, maybe
not. This should be clarified and made to work eventually.

> If i do, does that require something from my site to have both bindings
> active?

No, they'll be loaded automatically.

> Is this more or less the approach you have in mind too?
>
> I think that once we have a working approach, we should add an app which
> uses this approach.
> So all users will know how to include and use/extend wxLua in their own
> application.
> This is what wx(lua) is all about, so we better make as easy  as  possibl=
e.

This would be a good idea. I can make a very small demo, maybe just a
single little class, like a subclassed button.

I hope this helps,
    John Labenski

ps. I think I am very close to being done. I have removed the
wxLuaInterpreter class and replaced it completely with the wxLuaState
class in my own copy of the sources. The result of this seems to be
that it's fairly straightforward to understand the inner workings now.