wxlua-users

LUA_PATH (Ray) Re: [Wxlua-users] require("wx") and build stuff

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

On 5/17/06, Francesco Montorsi <f18...@ya...> wrote:
> Hi,
>     I'm experimenting with wx module and I've got a few proposals for it:
>
> 1) the luamodule.wx.lua files in wxLua/apps/luamodule/src is an example,
> isn't it ? Shouldn't then go in wxLua/samples ?
> wrapmodule.wx.lua is an utility so shouldn't it got in wxLua/utils ?

Eh... I think these are pretty specialized. But, you're probably
right, once things work they should be moved. I just put them into the
dir where I generated the shared lib since I was having trouble with
the paths for require.

> 2) I'm getting a weird behaviour of lua's require: I'd like to make the
> "luamodule" app installable in $prefix/lib/lua/5.1; however, while
> everything works as expected if I put the compiled wx.so in
> /usr/local/lib/lua/5.1, it doesn't work if I put it in /usr/lib/lua/5.1:

This is the path stuff I was talking about, it's a nightmare.

> wxlua-lua: luamodule.wx.lua:17: module 'wx' not found:
>          no field package.preload['wx']
>          no file './wx.so'
>          no file '/usr/local/lib/lua/5.1/wx.so'
>          no file '/usr/local/lib/lua/5.1/loadall.so'
> stack traceback:
>          [C]: in function 'require'
>          luamodule.wx.lua:17: in main chunk
>          [C]: ?
>
> I tried to set LUA_PATH in luamodule.wx.lua to:
> LUA_PATH=3D"/usr/lib/lua/5.1/?.so;"
> *before* the require() call but then I get:
>
> wxlua-lua: error loading module 'wx' from file '/usr/lib/lua/5.1/wx.so':
>          /usr/lib/lua/5.1/wx.so:1: unexpected symbol near 'char(127)'
> stack traceback:
>          [C]: ?
>          [C]: in function 'require'
>          luamodule.wx.lua:17: in main chunk
>          [C]: ?
>
> that "unexpected symbol near 'char(127)'" is not clear to me !
>
> This strange behaviour (lua bug?) is easy to reproduce also putting the
> wx.so file in /usr/local/lib/lua/5.1 and then setting:
>
> LUA_PATH=3D"/usr/local/lib/lua/5.1/?.so"
>
> So, it looks that the global variable LUA_PATH, described at
> http://www.lua.org/pil/8.1.html, does not work... is anyone able to
> reproduce this "bug" ?

LUA_PATH, I think, is a 5.0 thing, but recently Ray added some code in
our version of lua to handle it. Hopefully he (or anyone else)
understands what this is all about? I've spent far too much time
trying to understand the PATH thing and got nowhere.

I was hoping that the people who requested that require work w/ wxLua
would step forward and finish things. :)

Regards,
    John Labenski

ps. This was a reply I got on the lua-l about dlls and require, it
looks like for gcc in MSW you just link the dlls as you do the .so
files in linux. No news about MSVC.

On 5/13/06, J=E9r=F4me VUARAND <jer...@gm...> wrote:
> With mingw you can do exactly the same to build a wx.dll Lua module :
> wx.dll: luamodule.cpp $(OBJECTS) $(LUA_LIBS) wxLuaLib wxLuaDebugLib
> wxLuaSocketLib wxLuaBindings
>         $(CXX) $(CXXFLAGS) $(APPEXTRADEFS) -g -O -shared -o wx.dll -fpic =
\
>         $(LDLIBS) $(APPEXTRALIBS) \
>         luamodule.cpp
>
> The only extra thing you have to do is to check that all your
> -l$(XXXLIB) point to existing libraries. These libraries can either be
> static libs, or dll import libraries. Static libs are exactly like on
> unix (-lfoo need libfoo.a). Dll import libraries are necessary if you
> want to link dynamically to a dll. You can generate libfoo.a from
> foo.dll with the following commands :
>         impdef foo.dll > foo.def
>         libtool --kill-at --dllname foo.dll --input-def foo.def --output-=
lib libfoo.a
>         rm foo.def
> These import libraries may already exist in the wxWidget build tree if
> you built it with mingw.
>
> Feel free to ask if I'm not clear. I had a hard time finding docs on
> the subject since everything on mingw site is outdated, but now I
> think I know the subject well.

Re: LUA_PATH (Ray) Re: [Wxlua-users] require("wx") and build stuff

[Damien F. <dam...@mo...>]

 I have being using LUA_CPATH
setenv LUA_CPATH "...../lua/5.1/linux.fedora1/gcc3.3.4/?.so"
and  doing require "wx" in the scripts=20
 and it works fine=20

 I can`t remember when I found the documentation about it though :)

damien


> On 5/17/06, Francesco Montorsi <f18...@ya...> wrote:
> > Hi,
> >     I'm experimenting with wx module and I've got a few proposals for i=
t:
> >
> > 1) the luamodule.wx.lua files in wxLua/apps/luamodule/src is an example,
> > isn't it ? Shouldn't then go in wxLua/samples ?
> > wrapmodule.wx.lua is an utility so shouldn't it got in wxLua/utils ?
>=20
> Eh... I think these are pretty specialized. But, you're probably
> right, once things work they should be moved. I just put them into the
> dir where I generated the shared lib since I was having trouble with
> the paths for require.
>=20
> > 2) I'm getting a weird behaviour of lua's require: I'd like to make the
> > "luamodule" app installable in $prefix/lib/lua/5.1; however, while
> > everything works as expected if I put the compiled wx.so in
> > /usr/local/lib/lua/5.1, it doesn't work if I put it in /usr/lib/lua/5.1:
>=20
> This is the path stuff I was talking about, it's a nightmare.
>=20
> > wxlua-lua: luamodule.wx.lua:17: module 'wx' not found:
> >          no field package.preload['wx']
> >          no file './wx.so'
> >          no file '/usr/local/lib/lua/5.1/wx.so'
> >          no file '/usr/local/lib/lua/5.1/loadall.so'
> > stack traceback:
> >          [C]: in function 'require'
> >          luamodule.wx.lua:17: in main chunk
> >          [C]: ?
> >
> > I tried to set LUA_PATH in luamodule.wx.lua to:
> > LUA_PATH=3D"/usr/lib/lua/5.1/?.so;"
> > *before* the require() call but then I get:
> >
> > wxlua-lua: error loading module 'wx' from file '/usr/lib/lua/5.1/wx.so':
> >          /usr/lib/lua/5.1/wx.so:1: unexpected symbol near 'char(127)'
> > stack traceback:
> >          [C]: ?
> >          [C]: in function 'require'
> >          luamodule.wx.lua:17: in main chunk
> >          [C]: ?
> >
> > that "unexpected symbol near 'char(127)'" is not clear to me !
> >
> > This strange behaviour (lua bug?) is easy to reproduce also putting the
> > wx.so file in /usr/local/lib/lua/5.1 and then setting:
> >
> > LUA_PATH=3D"/usr/local/lib/lua/5.1/?.so"
> >
> > So, it looks that the global variable LUA_PATH, described at
> > http://www.lua.org/pil/8.1.html, does not work... is anyone able to
> > reproduce this "bug" ?
>=20
> LUA_PATH, I think, is a 5.0 thing, but recently Ray added some code in
> our version of lua to handle it. Hopefully he (or anyone else)
> understands what this is all about? I've spent far too much time
> trying to understand the PATH thing and got nowhere.
>=20
> I was hoping that the people who requested that require work w/ wxLua
> would step forward and finish things. :)
>=20
> Regards,
>     John Labenski
>=20
> ps. This was a reply I got on the lua-l about dlls and require, it
> looks like for gcc in MSW you just link the dlls as you do the .so
> files in linux. No news about MSVC.
>=20
> On 5/13/06, J=E9r=F4me VUARAND <jer...@gm...> wrote:
> > With mingw you can do exactly the same to build a wx.dll Lua module :
> > wx.dll: luamodule.cpp $(OBJECTS) $(LUA_LIBS) wxLuaLib wxLuaDebugLib
> > wxLuaSocketLib wxLuaBindings
> >         $(CXX) $(CXXFLAGS) $(APPEXTRADEFS) -g -O -shared -o wx.dll -fpi=
c \
> >         $(LDLIBS) $(APPEXTRALIBS) \
> >         luamodule.cpp
> >
> > The only extra thing you have to do is to check that all your
> > -l$(XXXLIB) point to existing libraries. These libraries can either be
> > static libs, or dll import libraries. Static libs are exactly like on
> > unix (-lfoo need libfoo.a). Dll import libraries are necessary if you
> > want to link dynamically to a dll. You can generate libfoo.a from
> > foo.dll with the following commands :
> >         impdef foo.dll > foo.def
> >         libtool --kill-at --dllname foo.dll --input-def foo.def --outpu=
t-lib libfoo.a
> >         rm foo.def
> > These import libraries may already exist in the wxWidget build tree if
> > you built it with mingw.
> >
> > Feel free to ask if I'm not clear. I had a hard time finding docs on
> > the subject since everything on mingw site is outdated, but now I
> > think I know the subject well.
>=20
>=20
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job ea=
sier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=120709&bid&3057&dat=121642
> _______________________________________________
> Wxlua-users mailing list
> Wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users

[Wxlua-users] Re: LUA_PATH (Ray) Re: require("wx") and build stuff

[Francesco M. <f18...@ya...>]

Damien Fagnou ha scritto:
> 
>  I have being using LUA_CPATH
> setenv LUA_CPATH "...../lua/5.1/linux.fedora1/gcc3.3.4/?.so"
> and  doing require "wx" in the scripts 
>  and it works fine 
> 
>  I can`t remember when I found the documentation about it though :)
it works but I was searching a way to set the path from the lua script 
itself...

Thanks anyway,
Francesco

Re: LUA_PATH (Ray) Re: [Wxlua-users] require("wx") and build stuff

[Hakki D. <dog...@tr...>]

Hi,

John Labenski yazmış:
> On 5/17/06, Francesco Montorsi <f18...@ya...> wrote:
>> Hi,
>>     I'm experimenting with wx module and I've got a few proposals for it:
>>
>> 1) the luamodule.wx.lua files in wxLua/apps/luamodule/src is an example,
>> isn't it ? Shouldn't then go in wxLua/samples ?
>> wrapmodule.wx.lua is an utility so shouldn't it got in wxLua/utils ?
> 
> Eh... I think these are pretty specialized. But, you're probably
> right, once things work they should be moved. I just put them into the
> dir where I generated the shared lib since I was having trouble with
> the paths for require.
> 
>> 2) I'm getting a weird behaviour of lua's require: I'd like to make the
>> "luamodule" app installable in $prefix/lib/lua/5.1; however, while
>> everything works as expected if I put the compiled wx.so in
>> /usr/local/lib/lua/5.1, it doesn't work if I put it in /usr/lib/lua/5.1:
> 
> This is the path stuff I was talking about, it's a nightmare.
> 
>> wxlua-lua: luamodule.wx.lua:17: module 'wx' not found:
>>          no field package.preload['wx']
>>          no file './wx.so'
>>          no file '/usr/local/lib/lua/5.1/wx.so'
>>          no file '/usr/local/lib/lua/5.1/loadall.so'
>> stack traceback:
>>          [C]: in function 'require'
>>          luamodule.wx.lua:17: in main chunk
>>          [C]: ?
>>
>> I tried to set LUA_PATH in luamodule.wx.lua to:
>> LUA_PATH="/usr/lib/lua/5.1/?.so;"
>> *before* the require() call but then I get:
>>
>> wxlua-lua: error loading module 'wx' from file '/usr/lib/lua/5.1/wx.so':
>>          /usr/lib/lua/5.1/wx.so:1: unexpected symbol near 'char(127)'
>> stack traceback:
>>          [C]: ?
>>          [C]: in function 'require'
>>          luamodule.wx.lua:17: in main chunk
>>          [C]: ?
>>
>> that "unexpected symbol near 'char(127)'" is not clear to me !
>>
>> This strange behaviour (lua bug?) is easy to reproduce also putting the
>> wx.so file in /usr/local/lib/lua/5.1 and then setting:
>>
>> LUA_PATH="/usr/local/lib/lua/5.1/?.so"
>>
>> So, it looks that the global variable LUA_PATH, described at
>> http://www.lua.org/pil/8.1.html, does not work... is anyone able to
>> reproduce this "bug" ?
> 
> LUA_PATH, I think, is a 5.0 thing, but recently Ray added some code in
> our version of lua to handle it. Hopefully he (or anyone else)
> understands what this is all about? I've spent far too much time
> trying to understand the PATH thing and got nowhere.
> 
> I was hoping that the people who requested that require work w/ wxLua
> would step forward and finish things. :)
> 
> Regards,
>    John Labenski
> 
[snip]

I'm using paths like this (on winxp):

DSASPATH = "c:/a_C/dsas/server/"

package.path  = 
DSASPATH.."?;"..DSASPATH.."?.lua;"..DSASPATH.."/apps/?;"..DSASPATH.."/apps/?.lua"
package.cpath = 
DSASPATH.."?;"..DSASPATH.."?.dll;"..DSASPATH.."/apps/?;"..DSASPATH.."/apps/?.dll"

require("testapp")         -- API testing
...



--
Regards,
Hakki Dogusan

[Wxlua-users] Re: LUA_PATH (Ray) Re: require("wx") and build stuff

[Francesco M. <f18...@ya...>]

Hakki Dogusan ha scritto:
> I'm using paths like this (on winxp):
> 
> DSASPATH = "c:/a_C/dsas/server/"
> 
> package.path  = 
> DSASPATH.."?;"..DSASPATH.."?.lua;"..DSASPATH.."/apps/?;"..DSASPATH.."/apps/?.lua" 
> 
> package.cpath = 
> DSASPATH.."?;"..DSASPATH.."?.dll;"..DSASPATH.."/apps/?;"..DSASPATH.."/apps/?.dll" 
> 
> 
> require("testapp")         -- API testing
> ...
> 
Exactly what I was looking for: package.cpath.
Works nicely here, thanks!

Francesco

[Wxlua-users] Re: LUA_PATH (Ray) Re: require("wx") and build stuff

[Francesco M. <f18...@ya...>]

John Labenski ha scritto:
> On 5/17/06, Francesco Montorsi 
> <f18...@ya...> wrote:
>> Hi,
>>     I'm experimenting with wx module and I've got a few proposals for it:
>>
>> 1) the luamodule.wx.lua files in wxLua/apps/luamodule/src is an example,
>> isn't it ? Shouldn't then go in wxLua/samples ?
>> wrapmodule.wx.lua is an utility so shouldn't it got in wxLua/utils ?
> 
> Eh... I think these are pretty specialized. But, you're probably
> right, once things work they should be moved. I just put them into the
> dir where I generated the shared lib since I was having trouble with
> the paths for require.
Ok, another thing which now comes to my mind: "luamodule" directory 
should probably be moved too, in wxLua/modules. In fact, it does not 
build any application at all, just a .so/.dll

BTW: I'd organize the thing as:
-> wx.so/dll is always placed in wxLua/lib (even if, in Unix, you're 
building from a different build folder, e.g. wxLua/mybuild)

-> luamodule.wx.lua sample uses
package.cpath = ";;../lib/?.so;..\lib\?.dll"
before the call to require("wx")

-> on Unix, wx.so is installed in  $prefix/lib/lua/5.1

Now, developers using wxLua which want to ship an application entirely 
written in wxLua, which uses the require("wx") notation, will just need 
to ship:

-> all DLLs/.so of wxLua/lib if they built wxLua as a shared library 
(SHARED=1)
-> wx.so/.dll if they built wxLua as a static library (SHARED=0).
    In fact, wx.so/.dll should be built regardless of the SHARED option 
value: when SHARED==1, it will just be a super-small file which tells 
the OS to load the other .so/.dll libraries; when SHARED==0, it will be 
a bigger lib (on my Unix, it is about 9,4 MB) which is self-contained.

What do you think ?

Francesco

[Wxlua-users] Re: LUA_PATH (Ray) Re: require("wx") and build stuff

[Francesco M. <f18...@ya...>]

Francesco Montorsi ha scritto:
> John Labenski ha scritto:
>> On 5/17/06, Francesco Montorsi 
>> <f18...@ya...> wrote:
>>> Hi,
>>>     I'm experimenting with wx module and I've got a few proposals for 
>>> it:
>>>
>>> 1) the luamodule.wx.lua files in wxLua/apps/luamodule/src is an example,
>>> isn't it ? Shouldn't then go in wxLua/samples ?
>>> wrapmodule.wx.lua is an utility so shouldn't it got in wxLua/utils ?
>>
>> Eh... I think these are pretty specialized. But, you're probably
>> right, once things work they should be moved. I just put them into the
>> dir where I generated the shared lib since I was having trouble with
>> the paths for require.
> Ok, another thing which now comes to my mind: "luamodule" directory 
> should probably be moved too, in wxLua/modules. In fact, it does not 
> build any application at all, just a .so/.dll
> 
> BTW: I'd organize the thing as:
> -> wx.so/dll is always placed in wxLua/lib (even if, in Unix, you're 
> building from a different build folder, e.g. wxLua/mybuild)
> 
> -> luamodule.wx.lua sample uses
> package.cpath = ";;../lib/?.so;..\lib\?.dll"
> before the call to require("wx")
> 
> -> on Unix, wx.so is installed in  $prefix/lib/lua/5.1
> 
> Now, developers using wxLua which want to ship an application entirely 
> written in wxLua, which uses the require("wx") notation, will just need 
> to ship:
> 
> -> all DLLs/.so of wxLua/lib if they built wxLua as a shared library 
> (SHARED=1)
> -> wx.so/.dll if they built wxLua as a static library (SHARED=0).
>    In fact, wx.so/.dll should be built regardless of the SHARED option 
> value: when SHARED==1, it will just be a super-small file which tells 
> the OS to load the other .so/.dll libraries; when SHARED==0, it will be 
> a bigger lib (on my Unix, it is about 9,4 MB) which is self-contained.
> 
> What do you think ?
Trying to get wx.dll working on Win32, too, I've found a lot of problems 
in building the DLLs of wxLua.

In particular, it looks like the different modules need somehow stuff 
which is in other modules to link so that I ended up to compile first 
all files and then link them all together in a single monolithic DLL 
library.

This is 99% because all modules use the same WXMAKINGDLL_WXLUA symbol 
while for various reasons they should use different ones for the 
different modules.

Since, in my personal experience, building as DLL can be a BIG pain (you 
have to be very careful about WXDLLIMPEXP symbols, inter-module 
dependencies and in general in the entire build system), I propose to 
make wxLua buildable as a set of modules when SHARED==0 and as a single 
monolithic DLL library when SHARED==1.

What do you think ?

Also, what about moving "luamodule" dir to wxLua\modules ? Can I commit 
that change ?

Thanks,
Francesco

Re: [Wxlua-users] Re: LUA_PATH (Ray) Re: require("wx") and build stuff

[Josh T. <zen...@ya...>]

I see I'm not the only one having problems.  In order for other binary modules to work with wxLua, wxLua needs to link against a seperate Lua.DLL, a DLL which the modules also link against.  In the current binary release of wxLua the only way to make it work is to rebuild all of the modules and have them link against wxLua.dll to get the lua symbols.

Please please please add/fix the SHARED options to the build system :)


I have 3D rendering working inside a wxFrame using wxLua and IrrLua.  

http://irrlua.sourceforge.net/14.wxWindow.lua

  Unfortunately it only works with wxLua 2.4 due to the linking issues I've described above, which this SHARED option would solve.

  Linking against the LuaBinaries would be best of all.  If everybody links against the same binaries, all of our modules will play together without the need for a recompile somewhere.  Just download the .DLL/.so and go.

" Trying to get wx.dll working on Win32, too, I've found a lot of problems 
in building the DLLs of wxLua.

In particular, it looks like the different modules need somehow stuff 
which is in other modules to link so that I ended up to compile first 
all files and then link them all together in a single monolithic DLL 
library.

This is 99% because all modules use the same WXMAKINGDLL_WXLUA symbol while for various reasons they should use different ones for the 
different modules.

Since, in my personal experience, building as DLL can be a BIG pain (you 
have to be very careful about WXDLLIMPEXP symbols, inter-module 
dependencies and in general in the entire build system), I propose to 
make wxLua buildable as a set of modules when SHARED==0 and as a single 
monolithic DLL library when SHARED==1.

What do you think ? "





		
---------------------------------
Ring'em or ping'em. Make  PC-to-phone calls as low as 1¢/min with Yahoo! Messenger with Voice.

[Wxlua-users] Re: LUA_PATH (Ray) Re: require("wx") and build stuff

[Francesco M. <f18...@ya...>]

Josh Turpen ha scritto:
> 
> I see I'm not the only one having problems.  In order for other binary 
> modules to work with wxLua, wxLua needs to link against a seperate 
> Lua.DLL, a DLL which the modules also link against. 
I know - it's the same issue described at

http://lua-users.org/wiki/BuildingModules

(see "Do Not Link Modules to the Lua Core Libraries"), right ?



> In the current 
> binary release of wxLua the only way to make it work is to rebuild all 
> of the modules and have them link against wxLua.dll to get the lua symbols.
> 
> Please please please add/fix the SHARED options to the build system :)
Just for curiosity: how did you manage to rebuild all modules ?
Hacking the makefiles ?


> 
> 
> I have 3D rendering working inside a wxFrame using wxLua and IrrLua. 
> 
> http://irrlua.sourceforge.net/14.wxWindow.lua
very interesting project !
Maybe we should add a "projects using wxLua" section in wxLuaWebsite...


> 
>   Unfortunately it only works with wxLua 2.4 due to the linking issues 
> I've described above, which this SHARED option would solve.
> 
>   Linking against the LuaBinaries would be best of all.  If everybody 
> links against the same binaries, all of our modules will play together 
> without the need for a recompile somewhere.  Just download the .DLL/.so 
> and go.
I think it should be not very difficult to reach this compatibility: we 
just need to build luamodule against the verbatim version of lua.

Francesco

Re: [Wxlua-users] Re: LUA_PATH (Ray) Re: require("wx") and build stuff

[Josh T. <zen...@ya...>]

<i>(see "Do Not Link Modules to the Lua Core Libraries"), right ?</i>
   
  No no no :)
   
   
  What's described in the wiki is <i>static</i> linking, not dynamic linking.  You do NOT want to statically link each module with the lua binaries, but you DO want to dynamically link.  This way each module is sharing a copy of the single lua binary, precisely what the wiki describes you want to do.
   
  The confusion comes from the fact that under windows, static libraries are called ".lib" files while .DLL import files are <i>also</i> called ".lib" files.  IIRC under unix there are no shared library <i>import</i> files.  You just link against the ".so" shared library, or the ".a" static library if you are linking statically.

  <i>Just for curiosity: how did you manage to rebuild all modules ?
Hacking the makefiles ?</i>
   
  Yes.  I only rebuilt a few (my own modules), but it worked fine after I did.

  
Francesco Montorsi <f18...@ya...> wrote:
    Josh Turpen ha scritto:
> 
> I see I'm not the only one having problems. In order for other binary 
> modules to work with wxLua, wxLua needs to link against a seperate 
> Lua.DLL, a DLL which the modules also link against. 
I know - it's the same issue described at

http://lua-users.org/wiki/BuildingModules

(see "Do Not Link Modules to the Lua Core Libraries"), right ?



> In the current 
> binary release of wxLua the only way to make it work is to rebuild all 
> of the modules and have them link against wxLua.dll to get the lua symbols.
> 
> Please please please add/fix the SHARED options to the build system :)
Just for curiosity: how did you manage to rebuild all modules ?
Hacking the makefiles ?

> 
> 
> I have 3D rendering working inside a wxFrame using wxLua and IrrLua. 
> 
> http://irrlua.sourceforge.net/14.wxWindow.lua
very interesting project !
Maybe we should add a "projects using wxLua" section in wxLuaWebsite...


> 
> Unfortunately it only works with wxLua 2.4 due to the linking issues 
> I've described above, which this SHARED option would solve.
> 
> Linking against the LuaBinaries would be best of all. If everybody 
> links against the same binaries, all of our modules will play together 
> without the need for a recompile somewhere. Just download the .DLL/.so 
> and go.
I think it should be not very difficult to reach this compatibility: we 
just need to build luamodule against the verbatim version of lua.

Francesco



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wxlua-users mailing list
Wxl...@li...
https://lists.sourceforge.net/lists/listinfo/wxlua-users



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Wxlua-users] Re: LUA_PATH (Ray) Re: require("wx") and build stuff

[Francesco M. <f18...@ya...>]

Josh Turpen ha scritto:
> <i>(see "Do Not Link Modules to the Lua Core Libraries"), right ?</i>
>  
> No no no :)
>  
>  
> What's described in the wiki is <i>static</i> linking, not dynamic 
> linking.  You do NOT want to statically link each module with the lua 
> binaries, but you DO want to dynamically link.  This way each module is 
> sharing a copy of the single lua binary, precisely what the wiki 
> describes you want to do.
yes, I meant that: latest wxLua (CVS or snapshots) does exactly that. 
When SHARED==1, it builds everything linking to DLLs and the "wx.dll" is 
created linking it against the verbatim lua core so that it should be 
compatible with all other lua modules.

Francesco

Re: [Wxlua-users] Re: LUA_PATH (Ray) Re: require("wx") and build stuff

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

On 5/19/06, Francesco Montorsi <f18...@ya...> wrote:
> > Ok, another thing which now comes to my mind: "luamodule" directory
> > should probably be moved too, in wxLua/modules. In fact, it does not
> > build any application at all, just a .so/.dll

See below, but the .so/.dll is a distributable usable product, like an app?

> > BTW: I'd organize the thing as:
> > -> wx.so/dll is always placed in wxLua/lib (even if, in Unix, you're
> > building from a different build folder, e.g. wxLua/mybuild)

Sure.

> > -> luamodule.wx.lua sample uses
> > package.cpath = ";;../lib/?.so;..\lib\?.dll"
> > before the call to require("wx")
> >
> > -> on Unix, wx.so is installed in  $prefix/lib/lua/5.1

Ok.

> > Now, developers using wxLua which want to ship an application entirely
> > written in wxLua, which uses the require("wx") notation, will just need
> > to ship:
> >
> > -> all DLLs/.so of wxLua/lib if they built wxLua as a shared library
> > (SHARED=1)
> > -> wx.so/.dll if they built wxLua as a static library (SHARED=0).
> >    In fact, wx.so/.dll should be built regardless of the SHARED option
> > value: when SHARED==1, it will just be a super-small file which tells
> > the OS to load the other .so/.dll libraries; when SHARED==0, it will be
> > a bigger lib (on my Unix, it is about 9,4 MB) which is self-contained.
> >
> > What do you think ?

Sounds good, would this account for the possibility of someone getting
the wxWidgets2.6.3.rpm so they have their .so files and build wxLua
(or someday we provide our own rpm that depends on the wxWidgets rpm)
then we'd just want our .so libs to link to the rpm's libs. Or is this
way too much to ask.

> Trying to get wx.dll working on Win32, too, I've found a lot of problems
> in building the DLLs of wxLua.
>
> In particular, it looks like the different modules need somehow stuff
> which is in other modules to link so that I ended up to compile first
> all files and then link them all together in a single monolithic DLL
> library.

It should be all top down from wxLuaSocket->wxLuaDebug->wxLua, no deps
the other way around.

> This is 99% because all modules use the same WXMAKINGDLL_WXLUA symbol
> while for various reasons they should use different ones for the
> different modules.

I had no idea. This is not a problem, we just need wxlsockdefs.h and
wxldebugdefs.h or something like that for each.

> Since, in my personal experience, building as DLL can be a BIG pain (you
> have to be very careful about WXDLLIMPEXP symbols, inter-module
> dependencies and in general in the entire build system), I propose to
> make wxLua buildable as a set of modules when SHARED==0 and as a single
> monolithic DLL library when SHARED==1.
>
> What do you think ?

I have never tried to build anything as a DLL except by accident. It's
probably a shame that I separated out the wxluadebug and wxluasocket
stuff from wxlua since it's so tiny compared to wxWidgets that the
size savings of not having them is quite negligible and it's a hassle
dealing with so many tiny parts.

> Also, what about moving "luamodule" dir to wxLua\modules ? Can I commit
> that change ?

I see it more as an app? It's an end product of wxLua to be used by a
user and it links to the other libs just like an app, even though it's
a lib. I thought it belonged in apps since you can't link to it unlike
the other wxLua modules. Sure, it's called module, but that's just
lua's name for "require" libs.

I'm off for the next couple days, if you still think it's a good idea, fine.

-------

I also had this in mind, the wxLuaFreeze and luamodule program may
want to be compiled with smaller sets of the wxWidgets bindings. This
is back to the old question of how to deal with different wxluasetup.h
files, the wxLua app should always have everything. Also, the
luamodule must have WXLUA_LUA_NEWTHREAD not #defined to use with a
stock version of the lua executable and again the wxLua program
*should* have it.

Of course you (I) don't want to have to compile wxLua w/ everything,
clean out the libs and rebuild, if you're a developer this can get
really annoying. Maybe the wxLuaFreeze and luamodule should just
compile the cpp files to their own private object files and be done
with it. There's nothing worse than compiling something with wrong
build options or #defines and when you get to end the linker complains
about missing parts, you've got to completely restart and people might
just get confused/annoyed and give up.

Additionally the wxLuaFreeze and luamodule might as well be linked to
the object files directly since they really ought to be monolithic
since they're distributable.

-------

Finally, can we output the object files into unique dirs for each
build setting. IIRC they're put in the same place for debug and
release in MSVC and configure w/ gmake, but I could be wrong, I can't
check right now.

Thanks for all your work Francesco, it'd be a pretty sorry state of
affairs without you.
    John Labenski

[Wxlua-users] Re: LUA_PATH (Ray) Re: require("wx") and build stuff

[Francesco M. <f18...@ya...>]

John Labenski ha scritto:
>> > -> all DLLs/.so of wxLua/lib if they built wxLua as a shared library
>> > (SHARED=1)
>> > -> wx.so/.dll if they built wxLua as a static library (SHARED=0).
>> >    In fact, wx.so/.dll should be built regardless of the SHARED option
>> > value: when SHARED==1, it will just be a super-small file which tells
>> > the OS to load the other .so/.dll libraries; when SHARED==0, it will be
>> > a bigger lib (on my Unix, it is about 9,4 MB) which is self-contained.
>> >
>> > What do you think ?
as a reply to my own thought - it's wrong: luamodule should never be 
built when SHARED==0. In fact, as written at 
http://lua-users.org/wiki/BuildingModules, our wx.dll/.so would embed in 
that case a duplicated copy of lua core, which must be avoided.
Thus I'll set luamodule buildable only when SHARED==1


> Sounds good, would this account for the possibility of someone getting
> the wxWidgets2.6.3.rpm so they have their .so files and build wxLua
> (or someday we provide our own rpm that depends on the wxWidgets rpm)
> then we'd just want our .so libs to link to the rpm's libs. Or is this
> way too much to ask.
This is definitevely possible and is the whole sense of building shared 
libraries. On Unix it already works (I'm using wxLua shared libs against 
Ubuntu's shared build of wxGTK 2.6.1).


> >> Trying to get wx.dll working on Win32, too, I've found a lot of problems
>> in building the DLLs of wxLua.
>>
>> In particular, it looks like the different modules need somehow stuff
>> which is in other modules to link so that I ended up to compile first
>> all files and then link them all together in a single monolithic DLL
>> library.
> 
> It should be all top down from wxLuaSocket->wxLuaDebug->wxLua, no deps
> the other way around.
Well, looking at docs/install.html and to current Makefiles (which I'm 
sure they work on linux), the link order is:

wxlua, [wxbindstc, ] wxbind, wxluasocket, wxluadebug, lua

where library X depends from libraries listed on its right (e.g. 
wxluasocket depends on wxluadebug and lua).

maybe it would be more correct to write that:

    wxlua depends from:          lua
    wxbind depends from:         lua
    wxbindstc depends from:      wxbind, lua
    wxluadebug depends from:     wxlua, lua
    wxluasocket depends from:    wxluadebug, wxlua, lua

I realize that I've never asked such important question and that these 
relations should definitevely be cleared.... please correct the above 
schema.


> 
>> This is 99% because all modules use the same WXMAKINGDLL_WXLUA symbol
>> while for various reasons they should use different ones for the
>> different modules.
> 
> I had no idea. This is not a problem, we just need wxlsockdefs.h and
> wxldebugdefs.h or something like that for each.
I'll look about it and let you know. This will be also a good occasion 
to learn more about wxLua internals :))


>> Since, in my personal experience, building as DLL can be a BIG pain (you
>> have to be very careful about WXDLLIMPEXP symbols, inter-module
>> dependencies and in general in the entire build system), I propose to
>> make wxLua buildable as a set of modules when SHARED==0 and as a single
>> monolithic DLL library when SHARED==1.
>>
>> What do you think ?
> 
> I have never tried to build anything as a DLL except by accident. It's
> probably a shame that I separated out the wxluadebug and wxluasocket
> stuff from wxlua since it's so tiny compared to wxWidgets that the
> size savings of not having them is quite negligible and it's a hassle
> dealing with so many tiny parts.
that's partially true... OTOH they solve quite different tasks so that, 
at least logically, having them separate is a good thing...


> 
>> Also, what about moving "luamodule" dir to wxLua\modules ? Can I commit
>> that change ?
> 
> I see it more as an app? It's an end product of wxLua to be used by a
> user and it links to the other libs just like an app, even though it's
> a lib.
well, also other libs link to other libs when built as DLL :)
I think it would be confusing for the user to have all modules' output 
placed in wxLua\lib and apps' output partially in wxLua\bin and 
wxLua\lib....

An application is something the user can run... an executable; luamodule 
produces a library which is usable more or less like all other wxLua 
libraries (if we say that luamodule is like an app, why not say that 
also for e.g. wxbind? :))


> I thought it belonged in apps since you can't link to it unlike
> the other wxLua modules.
The link happens dinamically but is always a link...

> Sure, it's called module, but that's just
> lua's name for "require" libs.
> 
> I'm off for the next couple days, if you still think it's a good idea, 
> fine.
Ok, I'll try to fix the DLL build adding 
WXDLLIMPEXP_{WXBIND|WXBINDSTC|WXLUA|WXLUADEBUG|WXLUASOCKET} and then 
eventually commit them.

> 
> -------
> 
> I also had this in mind, the wxLuaFreeze and luamodule program may
> want to be compiled with smaller sets of the wxWidgets bindings. This
> is back to the old question of how to deal with different wxluasetup.h
> files, the wxLua app should always have everything. 
I thought this issue was solved using the WXLUASETUP_DIR and 
WXLUABINDLIB_DIR options; if someone wants a minimal version of wxLua 
without affecting the wxLua executable he needs to keep its wxluasetup.h 
in its own project folder instead of modifying 
wxLua\modules\wxbind\setup\wxluasetup.h...

>Also, the
> luamodule must have WXLUA_LUA_NEWTHREAD not #defined to use with a
> stock version of the lua executable and again the wxLua program
> *should* have it.
ok, I'll then add a new target to the makefiles, "lua", which builds the 
verbatim version of lua 5.1 and then make luamodule build against it.

I could then add also a "lua" <exe> target so that in the end, building 
wxLua one would get:

in bin\:
   wxlua-lua[.exe]  <-- the lua interpreter with WXLUA_LUA_NEWTHREAD
   lua5.1[.exe]     <-- the lua interpreter WITHOUT WXLUA_LUA_NEWTHREAD

in lib\:
   wxlua_gtk2d_lua-2.7[.so/.dll]  <-- lua core with WXLUA_LUA_NEWTHREAD
   lua5.1[.so/.dll]  <-- lua core WITHOUT WXLUA_LUA_NEWTHREAD

the names lua5.1[.exe] and lua5.1[.so/.dll] are intentionally the same 
of the LuaBinaries project since we should not fear to overwrite the 
system's installations of these things since they will be identic to the 
ones provided by the LuaBinaries project...


> Of course you (I) don't want to have to compile wxLua w/ everything,
> clean out the libs and rebuild, if you're a developer this can get
> really annoying. Maybe the wxLuaFreeze and luamodule should just
> compile the cpp files to their own private object files and be done
> with it. There's nothing worse than compiling something with wrong
> build options or #defines and when you get to end the linker complains
> about missing parts, you've got to completely restart and people might
> just get confused/annoyed and give up.
> 
> Additionally the wxLuaFreeze and luamodule might as well be linked to
> the object files directly since they really ought to be monolithic
> since they're distributable.
well, wxLuaFreeze is monolithic when compiled with SHARED==0.
luamodule OTOH *needs* to be non-monolithic (i.e. it needs not to have 
lua core code inside it - see beginning of this reply).

When compiled with SHARED==1, you get a wxLuaFreeze which depends from 
wxLua dlls but that's what the user expects I think...


> 
> -------
> 
> Finally, can we output the object files into unique dirs for each
> build setting. IIRC they're put in the same place for debug and
> release in MSVC and configure w/ gmake, but I could be wrong, I can't
> check right now.
yes, I'll do it.


> 
> Thanks for all your work Francesco, it'd be a pretty sorry state of
> affairs without you.
Thanks for your great work on wxLua, which unfortunately I haven't 
managed to integrate with my other projects yet :(

BTW, wxLuaSudoku sample is now so complete, nice and native-looking 
that we could really propose it as a stock game of Gnome ;)

Francesco

Re: [Wxlua-users] Re: LUA_PATH (Ray) Re: require("wx") and build stuff

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

On 5/20/06, Francesco Montorsi <f18...@ya...> wrote:
> > >> Trying to get wx.dll working on Win32, too, I've found a lot of problems
> >> in building the DLLs of wxLua.
> >>
> >> In particular, it looks like the different modules need somehow stuff
> >> which is in other modules to link so that I ended up to compile first
> >> all files and then link them all together in a single monolithic DLL
> >> library.
> >
> > It should be all top down from wxLuaSocket->wxLuaDebug->wxLua, no deps
> > the other way around.
> Well, looking at docs/install.html and to current Makefiles (which I'm
> sure they work on linux), the link order is:
>
> wxlua, [wxbindstc, ] wxbind, wxluasocket, wxluadebug, lua

The link order is not so important unless something needs to be
initialized in one lib and used in another. I don't think we have that
problem anymore since we make people call the binding init functions
in their wxApp::OnInit.

> where library X depends from libraries listed on its right (e.g.
> wxluasocket depends on wxluadebug and lua).
>
> maybe it would be more correct to write that:
>
>     wxlua depends from:          lua
>     wxbind depends from:         wxlua, lua
>     wxbindstc depends from:      wxbind, wxlua, lua
>     wxluadebug depends from:     wxlua, lua
>     wxluasocket depends from:    wxluadebug, wxlua, lua
>
> I realize that I've never asked such important question and that these
> relations should definitevely be cleared.... please correct the above
> schema.

I've just changed a couple things, everything depends on wxlua.

> >> This is 99% because all modules use the same WXMAKINGDLL_WXLUA symbol
> >> while for various reasons they should use different ones for the
> >> different modules.
> >
> > I had no idea. This is not a problem, we just need wxlsockdefs.h and
> > wxldebugdefs.h or something like that for each.
> I'll look about it and let you know. This will be also a good occasion
> to learn more about wxLua internals :))

Heh. Ok I've see you've added the defs headers. Thanks.

> > -------
> >
> > I also had this in mind, the wxLuaFreeze and luamodule program may
> > want to be compiled with smaller sets of the wxWidgets bindings. This
> > is back to the old question of how to deal with different wxluasetup.h
> > files, the wxLua app should always have everything.
> I thought this issue was solved using the WXLUASETUP_DIR and
> WXLUABINDLIB_DIR options; if someone wants a minimal version of wxLua
> without affecting the wxLua executable he needs to keep its wxluasetup.h
> in its own project folder instead of modifying
> wxLua\modules\wxbind\setup\wxluasetup.h...

But, the apps, see below, will just use the same object files, but I
think your solution below will work.

> >Also, the
> > luamodule must have WXLUA_LUA_NEWTHREAD not #defined to use with a
> > stock version of the lua executable and again the wxLua program
> > *should* have it.
> ok, I'll then add a new target to the makefiles, "lua", which builds the
> verbatim version of lua 5.1 and then make luamodule build against it.
>
> I could then add also a "lua" <exe> target so that in the end, building
> wxLua one would get:
>
> in bin\:
>    wxlua-lua[.exe]  <-- the lua interpreter with WXLUA_LUA_NEWTHREAD
>    lua5.1[.exe]     <-- the lua interpreter WITHOUT WXLUA_LUA_NEWTHREAD
>
> in lib\:
>    wxlua_gtk2d_lua-2.7[.so/.dll]  <-- lua core with WXLUA_LUA_NEWTHREAD
>    lua5.1[.so/.dll]  <-- lua core WITHOUT WXLUA_LUA_NEWTHREAD
>
> the names lua5.1[.exe] and lua5.1[.so/.dll] are intentionally the same
> of the LuaBinaries project since we should not fear to overwrite the
> system's installations of these things since they will be identic to the
> ones provided by the LuaBinaries project...
>
>
> > Of course you (I) don't want to have to compile wxLua w/ everything,
> > clean out the libs and rebuild, if you're a developer this can get
> > really annoying. Maybe the wxLuaFreeze and luamodule should just
> > compile the cpp files to their own private object files and be done
> > with it. There's nothing worse than compiling something with wrong
> > build options or #defines and when you get to end the linker complains
> > about missing parts, you've got to completely restart and people might
> > just get confused/annoyed and give up.
> >
> > Additionally the wxLuaFreeze and luamodule might as well be linked to
> > the object files directly since they really ought to be monolithic
> > since they're distributable.
> well, wxLuaFreeze is monolithic when compiled with SHARED==0.
> luamodule OTOH *needs* to be non-monolithic (i.e. it needs not to have
> lua core code inside it - see beginning of this reply).
>
> When compiled with SHARED==1, you get a wxLuaFreeze which depends from
> wxLua dlls but that's what the user expects I think...

Makes sense.

> > Thanks for all your work Francesco, it'd be a pretty sorry state of
> > affairs without you.
> Thanks for your great work on wxLua, which unfortunately I haven't
> managed to integrate with my other projects yet :(

I haven't used it too much either. Working on wxLua itself has taken
most of my programming time.

> BTW, wxLuaSudoku sample is now so complete, nice and native-looking
> that we could really propose it as a stock game of Gnome ;)

That would be nice. Lets let things settle for a week or so and make
the 2.6.3 release. I have updated all of the binding files to 2.6.3,
but I haven't yet had a chance to put all the overloaded functions in
place since the generator program needs some tweaks to get it to work
right in some cases.

-John Labenski

[Wxlua-users] Re: LUA_PATH (Ray) Re: require("wx") and build stuff

[Francesco M. <f18...@ya...>]

John Labenski ha scritto:
>> > Thanks for all your work Francesco, it'd be a pretty sorry state of
>> > affairs without you.
>> Thanks for your great work on wxLua, which unfortunately I haven't
>> managed to integrate with my other projects yet :(
> 
> I haven't used it too much either. Working on wxLua itself has taken
> most of my programming time.
I understand :)
On my side, I'm affected by a grave form of the 
"never-really-complete-what-I-begin" syndrom ;)
So that I've got dozens of projects which I began but I've never 
completed: I start enthusiastic as soon as I find a problem with some 
tool I'm using (e.g. a bug/missing feature in wxWidgets); I start to 
work on that just to find that there's one more missing piece for 
implementing it .... and so on.


> 
>> BTW, wxLuaSudoku sample is now so complete, nice and native-looking
>> that we could really propose it as a stock game of Gnome ;)
> 
> That would be nice. Lets let things settle for a week or so and make
> the 2.6.3 release. I have updated all of the binding files to 2.6.3,
> but I haven't yet had a chance to put all the overloaded functions in
> place since the generator program needs some tweaks to get it to work
> right in some cases.
Ok, hopefully I'll manage to fix also borland builds...

Francesco