On 5/19/06, Francesco Montorsi <[EMAIL PROTECTED]> 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
-------------------------------------------------------
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
Wxlua-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxlua-users
