[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