wxlua-users

[Wxlua-users] #define WXWIN_COMPATIBILITY_2_4 1

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

Hi John,

I am still using the/my old wxLua  inside wxArt2D. Hoping for wxLua CVS 
to become usable, but maybe it already is?
Referring to non use of *.i files or at least other ways to generate 
them using Ray his ideas.

What impact will all that have on the current structure? Will the *.i 
files stay? Or will it be  a new aproach ?

The thing is, i will need to have Cmake files in there ( or my own 
wxart2d  copy ) for wxArt2D.
If the whole think is about to change i better wait, but if not, i will 
start on the current situation.
If i have the right Cmake files, i can add them to wxLua CVS or keep 
them seperate.
I think it would be best to add them, else i will need to find a way to 
combine at a latter stage in wxAr2tD, which is no fun.

In any case, i would like to know is the current version can be compiled 
with wx261, and if that is with

#define WXWIN_COMPATIBILITY_2_4 1

i think it should be:
 
#define WXWIN_COMPATIBILITY_2_4 0

as setup.h recomments.

And how does one tell wxLuaWrap.lua, does it really read the setup.h?

Thanks,

Klaas

Unclassified

Re: [Wxlua-users] #define WXWIN_COMPATIBILITY_2_4 1

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

On 7/29/05, k. holwerda <kla...@nl...> wrote:
> I am still using the/my old wxLua  inside wxArt2D. Hoping for wxLua CVS
> to become usable, but maybe it already is?

It currently doen't wrap "enums" and "builtin" functions in the cpp
wrapper files. It does compile and work otherwise. I cannot figure it
out, but gave up since we're going to get some new wrappers anyway.

> Referring to non use of *.i files or at least other ways to generate
> them using Ray his ideas.
>=20
> What impact will all that have on the current structure? Will the *.i
> files stay? Or will it be  a new aproach ?

I don't know, hopefully Ray's reading this and can comment, maybe he
has something, even if it's half done that we can use to bring wxLua
back to a working state and the rest of us can pitch in to polish it
off.

I made some suggestions about making the .i files look more like c++
so that making your own would be a simple matter of taking a header
file and just removing the stuff you don't want. You'd then be able to
run a diff program on the .i and the original header to compare. But,
I don't know what other's thought of it. Basicly, replace the
%endclass, %endenum by surrounding them using {} like in c++.

> The thing is, i will need to have Cmake files in there ( or my own
> wxart2d  copy ) for wxArt2D.

I'd like for you to use wxLua itself (if that's what you mean by "my
own wxart2d copy), just direct people to download it someplace
relative to your wxArt2D. That way we avoid the splintering we had
before. Remixing together code from various places is error prone and
laborous. Hopefully it'll work soon...

I think that we can easily have cmake files too, right? Cmake IIRC
generates the build files on the fly after you download the source and
run cmake. If the files it generates are given names that won't clash
with the files in CVS it'll be easy to have both of them together. You
could put them in the build dir or if there will be a few of them in
build/cmake right?

> In any case, i would like to know is the current version can be compiled
> with wx261, and if that is with
>=20
> #define WXWIN_COMPATIBILITY_2_4 1
> i think it should be:
> #define WXWIN_COMPATIBILITY_2_4 0
> as setup.h recomments.

I currently use it with COMPAT_2_4 =3D 1, I haven't tested it without
it, but Ray has made the wrapper files generate #if wxCHECK_VER around
different functions so that it should compile either way. If not, it's
just a matter of fixing the problems in the .i files and regenerating
the wrappers. Before we change anything we really have to wait for
Ray, since doing anything to the wrappers will be a waste of time
since I think they'll be replaced.

You're right in that we probably should focus on 2.6 since when we're
done 2.4 will be pretty ancient (it already is to some extent).

> And how does one tell wxLuaWrap.lua, does it really read the setup.h?

It tries to find your wxWidgets setup.h file the best it can and sets
values from it. See bindings/wxluawrap.lua and at the top there is
code to look for "wxSetup_h" if it's nil. You can also specify
wxSetup_h before you run wxluawrap.lua if the code fails for some
reason.

I hope this helps, I hope we can get going again...
    John Labenski

Re: [Wxlua-users] #define WXWIN_COMPATIBILITY_2_4 1

[klaas.holwerda <kho...@xs...>]

Hi,

John Labenski wrote:

>I don't know, hopefully Ray's reading this and can comment, maybe he
>has something, even if it's half done that we can use to bring wxLua
>back to a working state and the rest of us can pitch in to polish it
>off.
>  
>
Please Ray ;-) Can you give us some insight on how the new way will work?
 From that i and we can decide what to do next.
I understand you have more things on your hands ;-), so maybe the best 
way to releaf you is indeed adding what you have so far.
Even if its not ready yet.

>
>I don't know what other's thought of it. Basicly, replace the
>%endclass, %endenum by surrounding them using {} like in c++.
>  
>
Looks a good idea to me.
I don't know whta ctags can do here, but i do know that doxygen 
generates very complete XML on c++ structure.
I would be possible to use it maybe, if better? At least it parses C++ 
correctly in many ways, so that part is done.
But no matter how, if the *.i look like c++ headers, a diff becomes much 
easier.

>  
>
>>The thing is, i will need to have Cmake files in there ( or my own
>>wxart2d  copy ) for wxArt2D.
>>    
>>
>
>I'd like for you to use wxLua itself (if that's what you mean by "my
>own wxart2d copy), just direct people to download it someplace
>relative to your wxArt2D. 
>
That i want too, but can only be true if it has Cmake inside, which you 
have no problem with.

>I think that we can easily have cmake files too, right?
>
Yes.

> Cmake IIRC
>generates the build files on the fly after you download the source and
>run cmake.
>
right. So no polution, and it also generates all stuff outside in a user 
choosen build directory.
This is for me the glory of Cmake, since it makes it very easy to have 
all kinds of setups in parallel.
But bakefile is nice too, although i have to say that it limits the 
things one can do.
This is normal since all one can do is what a makefile can do, and those 
are normally part of the distribution.
With Cmake the users runs cmake (look at it as if it was bakefile), and 
of course this is more flexible in the way things can be setup.

>You
>could put them in the build dir or if there will be a few of them in
>build/cmake right?
>  
>
That is not possible. Since the idea is that the user chooses this build 
directory himself.
So several directories, will get a CMakeLists.txt file, and there will 
be the bin directory for the macros of Cmake.
If you search through wxArt2D for *.txt, you see how it is done (also 
wxLua).
In general those files or no more thten a list of source and header files.
In any case, it is not intrusive i think.
I will try to make it work for what is there now. Although I might wait 
for the coming Cmake2.2, since it has several nice enhancements that 
will make it easier and more clean.

>
>I currently use it with COMPAT_2_4 = 1, I haven't tested it without
>it, but Ray has made the wrapper files generate #if wxCHECK_VER around
>different functions so that it should compile either way. If not, it's
>just a matter of fixing the problems in the .i files and regenerating
>the wrappers. Before we change anything we really have to wait for
>Ray, since doing anything to the wrappers will be a waste of time
>since I think they'll be replaced.
>
>You're right in that we probably should focus on 2.6 since when we're
>done 2.4 will be pretty ancient (it already is to some extent).
>  
>
I will try it. Found why it did not read my setup.h, something stupid on 
my side ;-)
The things is that it reads setup.h from a place that is maybe not the best.
setup.h is copied to each flavour in the resulting lib of wxWidgets.
So one things that one is in use, while it lua reads another 
$WXWIN/include/wx/msw/setup.h
Is that one changes, one needs to remove the ones in the lib dirs, to 
make fresh copies.
All a bit confusing.
I think wxWidgets has bin setup to use setup.h from the lib dirs, it is 
first in the include path.
The other one is just there as a template for changing. So a way to have 
several settings/setups for libraries, without automatically 
overwritting the ones compiled already. This is what Cmake solves more 
elegant ;-) But at least wxWidgets has  done something to be able to do 
several types of setup.h files around. So i think we should read the 
last in the lib dirs. 2.5.0 > does this all like that, so if we skip on 
2.4.0, we are save.
 

>I hope this helps, I hope we can get going again...
>  
>
Yes thanks a lot!

I wish i knew a bit more of wxLua in order to help you, but i am afraid 
that  i have to the depend  on you and Ray to make a start,  then i will 
do my best to  join. wxArt2D is taken most of my time, but once wxLua is 
nicely in adding extrernal wrappers, that will save time there ;-)

Best regards,

Klaas