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