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