From: Francesco M. <f18...@ya...> - 2006-12-11 00:06:24
|
John Labenski ha scritto: > On 12/9/06, Francesco Montorsi <f18...@ya...> wrote: >> 1) renamed "app_lua" to "app_verbatimlua" to be coherent with the >> relative module which is called "verbatimlua_lib". > > I think it might be better/simpler to just name it app_lua and > lib_lua, since we only have one copy of lua now. however the "verbatim" attribute suggests that those are "vanilla" versions of lua - so I'd rather keep it. >> 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 > > Good idea, I guess the lua lib really only has two forms release and > debug though? yes, exactly... however it's really much easier to name it using wxLua rules even if e.g. libwxlua_gtk2d_lua-2.8.a is going to be (I haven't tested) identical to libwxlua_gtk2ud_lua-2.8.a (note the "u"). >> 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? > > No problem I think it's good. I have a feeling that if we decided to use lua5.1 as libname there was a reason behind it. Maybe it has something to do with DLLs and the wx.dll module ? > >> 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 > > What about just using the wxlike-lib for wxlua too? That way the > wxCode bakefiles will be able to use the libs it generates very > easily. This is why I'm so interested in naming all the libs using > wxWidgets like the wxWidgets libs since it becomes easy to mix > everything together. I'd say that we shouldn't remove the "wxlua" prefix from our libraries but rather modify wxCode's <wxlike-lib> tag to accept a "prefix" attribute just as <wxlike-libname> and <wxlike-dllname> currently do. Unfortunately this is a bit backward-incompatible since if I modify <wxlike-lib> tag definition (in wxCode bakefiles) to use $(attributes['prefix']) with the current bakefile it would crash if you use the <wxlike-lib> tag without explicitely give a prefix attribute; i.e. <wxlike-lib>test</wxlike-lib> would give a Python error when baking saying that attributes['prefix'] is used but it does not exist (not defined). This is a problem with bakefile and guess what: I've submitted a patch to fix a long time ago but it's still not part of bakefile. In conclusion, I'd currently keep wxLua libs named as they are now and in future modify <wxlike-lib> in wxCode bakefiles to take that "prefix" extra attribute. >> I'm sorry I could only test these changes on Unix right now. >> Tomorrow I'll test them on Windows, too. > > Sounds great, I have some commits on the wxLua program to finish and > then I'll try it in VC6. > > And of course one more thing... > > Do we need to put the executables in different dirs as well? This is > part of the problem that Klaas is having when he said that when he > tries to build both debug and release you can only do one (at least in > MSVC) since it thinks the exes are up to date and won't do the other > build. I really like having the exes in the bin dir, but being able to > have multiple builds compiled at once is also nice on my slow MSW > machine. ok, I'm committing now this change to CVS. The output lib folders will be named e.g. "bin/vcud_dll" or "bin/mingwd_lib", etc. The commit I'm doing also adds PCH support to wxLua. I was tired of the super-long compilation times; even if I don't have benchmarks I can say that it got a little better (i.e. faster) here after adding PCH... Unfortunately once more I've only tested these changes on Unix... Francesco |