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
-------------------------------------------------------
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
