Hi John,
here is a list of the fixes I've checked in:
1) renamed "app_lua" to "app_verbatimlua" to be coherent with the
relative module which is called "verbatimlua_lib".
2) renamed lua5.1 library built by wxLua to libwxlua_gtk2d_lua-2.8.a;
that is, to a lib which follows wxLua naming conventions. This is more
coherent with the way we call the (vanilla) lua intepreter which we
build: wxlua-lua. That is, if we care about not replacing the
system-wide "lua" executable, we should care also about not replacing
the system-wide "lua5.1" library.
I don't remember why we decided to call our verbatim lua library
"lua5.1"... do you see anything wrong with calling it using our naming
convention?
3) removed those wxlhandl* files you asked
4) removed unused DSP files and updated wxLua.dsw (which is not
updated automatically)
5) added the wxlike-lib tag to wxLua bakefiles, as well as a
AM_SET_WXLIKE_LIBNAME macro to properly detect and link to the wxStEdit
library
I'm sorry I could only test these changes on Unix right now.
Tomorrow I'll test them on Windows, too.
Francesco
BTW: thanks for remembering me about wxlike-lib tag; I forgot that in
the "wxpresets big enhancement" patch which I submitted to wxWidgets
project - added now.
Hopefully if/when that patch will be part of wxWidgets we will be able
to remove a lot of stuff from wxLua CVS ;)
John Labenski ha scritto:
> Finally, is it possible to copy this in build/bakefiles/wxluabase.bkl
> <define-tag name="wxlua-lib" rules="exe,dll,module">
> for stedit? Maybe just making it a wxlike-lib as used in wxcode?
> <define-tag name="wxlike-lib" rules="exe,dll,module">
>
> I think it's the same as the wxlua libs, just without the leading
> "wxlua_". Hopefully we'll be able to build it right out of the box.
> Currently you have to copy the wxStEdit lib to just stedit.lib.
>
> Thanks,
> John Labenski
>
>
>
>
>
> On 12/8/06, John Labenski <[EMAIL PROTECTED]> wrote:
>> On 12/8/06, Francesco Montorsi <[EMAIL PROTECTED]> 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, maybe
>> just a rebake will do it? 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 as you said, 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. I
>> would like you to rebake them so that when I try to redo it without
>> any changes no files should be modified and I'll know that things are
>> working.
>>
>> Thanks,
>> John Labenski
>>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
wxlua-users mailing list
wxlua-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxlua-users
