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

[k. h. <kla...@nl...>]

John Labenski wrote:

>On 7/31/05, klaas.holwerda <kho...@xs...> wrote:
>  
>
>>included from  in internal.cpp
>>
>>Where is  it?
>>    
>>
>
>see my other message, it's generated on the fly by running wxluawrap.lua.
>  
>
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??

I think we should have to a default binding library.
And if the user wants has own specific set, he can do so.

>I don't know about the bakefiles, but just to clarify the reasoning I
>think the only workable solution for having multiple versions of the
>wrapper libraries is to make people compile them in their own project.
>  
>
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.

So have a table of the next and not just one:

WXLUACLASS *GetClassList(size_t &count)
{
    static WXLUACLASS ClassList[] =
    {

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.

>For example, the standalone wxlua ide should wrap everything, all the
>wxLUA_USE_XXX are 1.
>
Right, this i see a s a default binding library.

> However for using wxLua in your own project you
>might want to turn some of them off.
>
I can understand, it would be ideal if this can be done at runtime?
If not there is only one solution, one has to switch them off, and 
recompile the library.
If this is inclusive the user wrappers/bindings, is for me just a matter 
of organizing things.

> I will want to be able to compile
>both of them without too much problem for debugging so I don't want to
>have to compile the wrapper lib for the standalone program, have to
>edit something and recompile it for an embedded program.
>
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.

So when i see in internal.cpp a line like this, i am lost ;-)

#include "../../../bindings/wxwidgets/luasetup.h.in" // get the base 
library

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?

> You shouldn't
>have to edit anything.
>  
>
Do you mean that for the moment having several luasetup.in  files, one 
leading to one libary another to another library would be oke?
This is the situation i had sofar in wxArt2D, several luasetup.h.in 
files, which are configured to the build tree as several luasetup.h
files. But now i realize that the luasetup.h is never used, it is 
generated by wxluawrap.lua from luasetup.h.in too.
Where is the generated luasetup.h meant for?

>I hope this makes sense,
>
>  
>
Not all ;-)
But with your help i might be able to understand what is the current 
situation, and next think about what we really want and how.
To me it is clear that when one wants to disable functionality of a 
default distributed wxLua library, this can only de done at run time. 
Which to me would not be a problem, since i never bother about size.
Next to this we can of course make a system that generates based on  an 
application luasetup.h, a new set of cpp files ( seperated by wxlua, 
thridparty, userapp  based on some sort of namespace in that setup.h file.)
This would than lead to a new wxLua_userapp library, meant only for that 
application, and does contain only code that was meant to be used by the 
application.

One thing for sure, we need to aim for a speration in  *.cpp files 
containing wrapping code. Currently adding one extra lua command to my 
app, takes long compilation time, and therefore is bad in a debug cylce.

What do you think, or do you have something else in mind.

Thanks,

Klaas

Unclassified