wxlua-users

Re: [wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

[John L. <jla...@gm...>]

On 12/8/06, Francesco Montorsi <f18...@ya...> wrote:
> Francesco Montorsi ha scritto:
> >> It looks like the object files for VC for the mod_wxlua (for example)
> >> go into wxLua/modules/build/msw/msvc6prjd/mod_wxlua for all of these
> >> builds
> >>
> >> I think it's ok for for monolithic and multilib, but the dll ones have
> >> to go somewhere else since if you use batch build in VC to build both
> >> Debug and DLL Debug it starts getting all sorts of errors/warnings
> >> about wrong function signatures after the first lib is compiled since
> >> I assume that it's using the same object files for both, but the
> >> WXEXPORT is different.
> > Ok, I'll set BUILDDIR to something like
> > "compiler-name[u][d]_shared/static" so that there should be no clashes
> > anymore.
> I've tested my changes also under Windows but I've just noticed a thing: how
> could object files for the two types of build conflict since statically-compiled
> object files are named "wxbind_lib_etcetc" while shared-compiled are named
> "wxbind_dll_etcetc" ?
> They also go in different folders (e.g. vc_lib and vc_dll) so maybe my change to
> BUILDDIR didn't help...

I don't get any errors now, so I think it fixed it! I used batch build
and built the multilib debug and debug DLL at the same time. I do see
that VC creates a binary BuildLog.htm (which is not html at all) in
the *.obj dir and maybe that messes things up? wxWidgets also
separates the files so I think it's probably necessary.

Could you remove the /D WXLUA_LUA_NEWTHREAD since we don't need it? I
don't see it in the bakefiles, but it's in modules_mod_lua.dsp. I will
edit the docs to remove the comment about it.

Also, the lua.5.1.lib and exe is linked to all the wxwidgets libs, can
that be turned off?

Also maybe we should remove modules_mod_verbatimlua.dsp and the
verbatim build and just have modules_mod_lua.dsp since we only have
one lua now. Same here, apps/build/msw/apps_app_verbatimlua.dsp. They
look identical to me except for the name.

Finally could you remove these two files before rebaking since we
don't need them anymore now that the debugger server is a
wxEvtHandler.
wxLua/modules/wxluasocket/src/wxlhandl.cpp
wxLua/modules/wxluasocket/include/wxlhandl.h

Could you do this stuff? I will definitely try to build your bakefile
this weekend and see if I can manage the files myself in the future.
The last time (months ago) I ran bakefile_gen with no changes to
anything it rewrote all the files, but it was hard for me to tell
exactly what it did by diffing them so I gave up.

Thanks,
     John Labenski

Re: [wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

[Francesco M. <f18...@ya...>]

John Labenski ha scritto:
> On 12/6/06, Francesco Montorsi <f18...@ya...> wrote:
>> John Labenski ha scritto:
>>> I have rewritten the coroutine code so that we do not have to replace
>>> luaE_newthread and luaE_freethread by pushing the wxLuaStateRefData
>>> into the registry table.
>> good work!
>>
>>> Hopefully this will make using wxLua as a lua module using require
>>> much easier... of course the build files have to sorted out.
>> I'll reorganize the bakefiles tonight ;)
>>
>> With bakefile 0.2.1 we are very very near to have all functionalities we
>> need in the "official" bakefile. In fact, the only thing which makes us
>> depend on a patched bakefile currently is that we want to:
>>
>>   1) use wxPresets and all logic they contain
>>   2) have WX_DEBUG=0/1 and WX_UNICODE replaced by BUILD=debug/release
>> and UNICODE option names
>>
>> if we remove "feature" #2 then we can use bakefile 0.2.1
>> if we don't, hopefully Vaclav will apply my patch for bakefile 0.2.2
>> (I'm pinging him about that patch since a long time now).
> 
> Hopefully, soon. :)
hopefully ;)
So, AFAIU, we'll keep in use the patched bakefile version.
I.e. we keep BUILD and UNICODE option names, right?

> Is the bakefile on the wxLua website the same one you're using
> (htdocs/bakefile/frm-bakefile.tar.gz). I haven't tried it yet, since
> this would be the first time I'd need it. If not could you update it
> if it's not too much trouble?
sure - I've updated it just taking a vanilla bakefile repo and applying 
the "condvar" patch - that is the patch which makes it possible to 
rename WX_DEBUG=>BUILD and so on...

To work with it on wxLua I only need to replace the <srcdir> tags 
scattered in wxLua bakefiles with the mostly-equivalent <set-srcdir> tag 
which is now supported by bakefile.


>> Is there any other build problem which I should solve this evening ?
> 
> I don't think so. I dunno what you want to do about naming the lua.exe
> and lua.dll. Do we put wx in it somewhere since some linux
> distributions have lua packages and we don't want to overwrite it for
> "make install" even though it's identical?
looking into apps.bkl we have:

     <exe id="app_lua" template="luainterpreter">
         <!-- avoid clashes with the verbatim lua interpreter and call 
it 'wxlua-lua' -->
         <exename>wxlua-lua</exename>
         <wxlua-lib>lua</wxlua-lib>
     </exe>

     <!-- the verbatim LUA interpreter (compiled without 
WXLUA_LUA_NEWTHREAD define) -->
     <exe id="app_verbatimlua" template="luainterpreter">
         <exename>lua5.1</exename>
         <sys-lib>lua5.1</sys-lib>
     </exe>

that is, we actually build a vanilla LUA interpreter and we call it 
lua5.1 like it's common to do in unix distro... so that we are currently 
replacing the system's lua5.1 executable with our vanilla one which 
should be identic.

Maybe we should avoid to do that since users may have installed in the 
system a custom lua5.1 executable.

So I'd say we should remove the app_verbatimlua <exe> and keep only 
app_lua (which uses "wxlua-lua" name).

I'm doing all required changes to wxLua bakefiles right now.
I'll commit them as soon as they are complete.

Francesco

Re: [wxlua-users] build system update (was Re: wxLua now uses an unmodified copy of lua 5.1.1)

[klaas.holwerda <kho...@xs...>]

Francesco Montorsi wrote:
> Klaas Holwerda ha scritto:
>   
>> All in all i think i still like this a little more:
>>
>> wxlua_msw28d_debug.lib
>>
>> compared to:
>>
>> wxmsw28d_wxlua_debug.lib
>>
>> The namespace in the beginning is easier when it comes to sorting (ls or dir will show them grouped ).
>>     
> I agree, I like to see "wxlua" as a prefix instead of having it in the middle.
>
>
>   
>>>> ps. The precompiled headers are GREAT! I can't really tell much of a
>>>>         
>>> difference in MSVC6, but I was thinking about how we could do it and
>>> wanted to ask if you knew how, but thought it might be too much work.
>>>       
>> Well in wxArt2D we have it working. The idea is this:
>>
>> // our own pre compiled header file.
>> #include "general/include/a2dprec.h"
>>
>> #ifdef __GNUG__
>>      #pragma implementation "artglob.h"
>> #endif
>>
>> #ifdef __BORLANDC__
>>      #pragma hdrstop
>> #endif
>>
>> #ifndef WX_PRECOMP
>>      #include "wx/wx.h"
>> #endif
>>
>>     
> well, I'd say that we should infact have a wxluaprec.h file
sure. I think you mean that in my case

#include "wxart2d.h" is not really needed inside the #include "general/include/a2dprec.h"?

But i use it for other cases when no PCH is in question.

>  and then put all 
> possible headers there and all other unnecessary #include directives into the 
> WX_PRECOMP block.
>
> I think we should also remove these blocks:
>
> #if defined(__GNUG__) && !defined(NO_GCC_PRAGMA)
>      #pragma implementation "wxlstate.h"
> #endif
>
> GCC does not use it anymore since a long time and they can only give problems...
>   
Very right, i still needed to that.

Klaas