Re: [wxlua-users] makefile.vc has wrong path to lib for DLLs

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

John Labenski ha scritto:
> Everything else seems great, I'm using VC 2003 and nmake.exe and both
> release and debug work even with the wxStEditor lib!
great!


> But, for SHARED=1 the paths for the dlls are
> ..\..\lib\wxmsw_msw26_wxlua.dll
> but should be
> ..\..\..\lib\[vc_dll]\wxmsw_msw26_wxlua.dll
> 
> Also, I see in the changelog that lib\vc_dll is now only \lib, see
> line 305 here.
> http://wxlua.cvs.sourceforge.net/wxlua/wxLua/modules/build/msw/makefile.vc?r1=1.53&r2=1.54
> 
> I can't find the change to common.bkl? that caused this.
I did a dummy change which removed vc_dll; fixed now, sorry.


> wxWidgets seems to build it's libs in only
> lib/vc_lib  for all lib builds release, debug, unicode
> lib/vc_dll  for all dll builds release, debug, unicode
> 
> Can we change it to this? Is this something else that should be in the
> WX_PRESETS? In addition to wxWidgets style lib names, also wxWidgets
> style lib paths?
good idea, maybe I should add a <set-wxlike-builddir/> tag and a 
<wxlike-dirname/> tag. I'll surely look at this!


> I think the only reason to separate lib builds is that if you build a
> lib you get *.lib, but if you buid a dll with the same release, debug,
> unicode settings you get *.lib + *.dll and the *.libs have the same
> names, but conflict due to the DLLIMPEXP symbols.
sure, but currently vc_lib and vc_dll subdirs are already used.

> Finally, (and this is only if it's easy) can we output the *.obj files
> to just "vc_msw[u][d][dll]" like wxWidgets does? Again maybe this
> belongs in WX_PRESETS so that a uniform *.obj file directory structure
> is used. (I know this is not important, but if the code could be in
> the WXPRESETS once it doesn't have to be duplicated.)
right, I've done that for wxLua bakefiles and rebaked. I'll look about a 
<set-wxlike-builddir/> tag for wxpresets.


> Sigh... all this would be so much easier if we could just the
> wxWidgets bakefiles in user projects (as I showed how it could be done
> years ago).
sorry but I don't completely agree. wx bakefiles are a huge set of 
bakefiles and debugging them is a nightmare; they're also completely 
oriented to wx itself, not for wx-based programs. I think wxpresets are 
the way to go.
If only my patches were accepted I would be much happier. But it looks 
like there's a solid wall of indifference toward bakefile+wxpresets issue.

Francesco