On 5/20/06, Francesco Montorsi <[EMAIL PROTECTED]> 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
-------------------------------------------------------
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
