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
_______________________________________________
wxlua-users mailing list
wxlua-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxlua-users

Reply via email to