Re: [Wxlua-users] wxbind/include/wxbind.h

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

On 8/1/05, k. holwerda <kla...@nl...> wrote:
> But that is confusing, i mean i thought that ..../modules/wxlua would be
> a library by itself.
> But if it needs wxbind.h which is not yet generated??

Yes the code can be pregenerated, but lets not put it into CVS until
we're happy with it since it's easy to generate on the fly. We can
remove the dependence on wxbind.h eventually, see below.

> Right now that is true, but if we change wxLuaWrap.lua here and there,
> we can have several wrapper trees ( one for the wxLua and one for a
> thirdparty lib (e.g. wxArt2DLua) and one for the user app ).
> More imported several generated Cpp files, one for each tree. The idea
> was to generate a sort of namespace for the each tree.

That is the idea, we can make wxluawrap.lua generate bindings for any
given set of .i files.
=20
> So have a table of the next and not just one:
> WXLUACLASS *GetClassList(size_t &count)
> {
>     static WXLUACLASS ClassList[] =3D
>     {

I think that in order to make all the bindings independent we should
use a class with static members. Change wxLuaBinding to something like
this

class wxLuaBinding
{
     wxLuaBinding() {}
     static size_t GetBindingCount() { return ms_nameSpaceArray.GetCount();=
 }
     static wxString GetNameSpace(size_t n) { return ms_nameSpaceArray[n]; =
}
     static WXLUACLASS* GetClasses(size_t n) { return
(WXLUACLASS*)ms_classArray[n]; }
     static WXLUAEVENT* GetEvents(size_t n) { return
(WXLUAEVENT*)ms_eventArray[n];
    ...
    =20
    // all arrays are the SAME size even if they have NULL pointers
    static wxArrayString   ms_nameSpaceArray;
    static wxArrayPtrVoid ms_classArray;
    static wxArrayInt        ms_classCountArray;
    static wxArrayPtrVoid ms_eventArray;
    static wxArrayInt        ms_eventCountArray;
    static wxArrayPtrVoid ms_defineArray;
    static wxArrayInt        ms_defineCountArray;
    ...
}

in the cpp wrapper files for wxWidgets (or your binding) have this

class wxLuaBinding_wx : public wxLuaWrappers
{
      wxLuaBinding_wx(void* classes, int class_count, void* events,
int event_count, void* defines, int define_count)
      {
         ms_nameSpaceArray.Add(wxT("wx"));
         ms_classArray.Add(classes);
         ms_classCountArray.Add(class_count);
         ms_eventArray.Add(events);
         ms_eventCountArray.Add(event_count);
         ms_defineArray.Add(defines);
         ms_defineCountArray.Add(define_count);
     }
}

// now add them by creating a dummy instance of the class who's only
purpose is to add the structs to the arrays. this way no special
functions have to be called.
wxLuaBinding_wx dummy_instance(just use the structs themselves here
and the WXSIZEOF them);

Now from *anywhere* in your program (probably only used internally
though) you just call this (with appropriate checks first).

wxLuaBinding::GetClasses(index of wrapper)[index into classes].whatever;
=20
Now the wrappers are completely independent and are added at your
program's startup depending on what you linked to. If you don't link
to any, it's just as well since the arrays will be empty and you get
no wrappers. There's no special functions to know the names of ahead
of time and everything is created on the fly depending on what you
link to. You just have to make sure that you get the link order right,
link to wxlua before any bindings.

This is trivial to implement, but is a fairly big change to
wxluawrap.lua and internals.h/cpp, so I was waiting for Ray so we
wouldn't have two different wxluawrap.lua files that had to be merged
again...

> I once looked at that, but stopped when the ctags came about.
> I wonder if the *.i files will stay even if using ctags approach or
> whatever way of generating the *.i files?
> If the *.i files will go, and there will be a speration in bindings
> libraries anyway, i will not spend time on the above.

No the .i files will probably stay since the generator will be used
for your own wrappers and it should work to recreate it's own wrappers
as a test.

> To this is only possible, if that is done at runtime.
> Else you will have to compile a library of the standalone, and another
> for the user app containing less bindings.
> Do i miss something?
>
> Still it is of course a could thing to be able to use several luasetup.h
> files.

This is exactly what I was thinking, you copy the makefile (buildfile)
from the wxbind dir into your program's dir, change paths accordingly
and then run it. Now you've generated your own library of wxLua's
wxwidgets bindings specificly for your program's needs. I can think of
no other way.
=20
> So when i see in internal.cpp a line like this, i am lost ;-)
>=20
> #include "../../../bindings/wxwidgets/luasetup.h.in" // get the base
> library
>=20
> It says include a file, which normally is meant to be configured??
> It seems wxluawrap.lua is doing that step, but  still internal.cpp
> includes all.
> Is that because it will be always a subset?

That was a hack I believe, using the above static functions in
wxLuaBinding we should be able to remove that include as well as the
include for wxbind.h since we will get all the info we need from the
static functions in wxLuaBinding. In fact there will be NO public
header for the wrapper libs as any information about them is set
internaly through wxLuaBinding.

Does this make more sense, even though we probably shouldn't do it yet
(until we know if there are better wrappers or now)... this is how I
envision it will work.
    John Labenski