wxlua-users

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

[John L. <jla...@gm...>]

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

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.

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?

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.

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.)

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). That way wxWidgets users use the same bakefile code as the
library itself and guarantee that everything is the same and any
updates to wxWidgets don't have to be duplicated in the wxpresets!
Grrrr :/

Thanks,
     John Labenski

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

[klaas.holwerda <kho...@xs...>]

John Labenski wrote:
> Everything else seems great, 
It does, every day its better :-)
> I'm using VC 2003 and nmake.exe and both
> release and debug work even with the wxStEditor lib!
>   
Yep. just setting WXSTEDIT as env., where would we be without Francesco :-)

Should we change the default to 2.8 now? In the makefiles i mean.
> 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
>   
Right.
>
> 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? 
I think that was the idea already,  there is already the vc_dll created. 
Or am i miss understanding something?

> Grrrr :/
>   
WX_PRESETS i think Francesco has nightmares around this word :-)

Klaas

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

[John L. <jla...@gm...>]

On 12/15/06, klaas.holwerda <kho...@xs...> wrote:
> John Labenski wrote:

> > 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?
> I think that was the idea already,  there is already the vc_dll created.
> Or am i miss understanding something?

Oops, you're right. I was looking at the bin/ directory where, yes, we
do have to give them all unique names. Nevermind.

> > Grrrr :/
> >
> WX_PRESETS i think Francesco has nightmares around this word :-)

Heh. :(

-John Labenski

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

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

klaas.holwerda ha scritto:
> John Labenski wrote:
>> Everything else seems great, 
> It does, every day its better :-)
>> I'm using VC 2003 and nmake.exe and both
>> release and debug work even with the wxStEditor lib!
>>   
> Yep. just setting WXSTEDIT as env., where would we be without Francesco :-)
Thanks ;)

> 
> Should we change the default to 2.8 now? In the makefiles i mean.
right, I've done it and committed.


>> Grrrr :/
>>   
> WX_PRESETS i think Francesco has nightmares around this word :-)
I just hope that all my work won't be rejected with a "it doesn't make 
sense" short sentence as it was 2-3 years ago (but I admit that at that 
time my patch was a bit messy).

Francesco

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

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

[Hakki D. <dog...@tr...>]

Hi,

John Labenski wrote:
> Everything else seems great, I'm using VC 2003 and nmake.exe and both
> release and debug work even with the wxStEditor lib!
> 
> 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
> 
[snip]

FYI,

(cvs 2006-12-17, wx2.8, winxp)

I tried with mingw:
mingw32-make -fmakefile.gcc WX_VERSION=28 WX_MONOLITHIC=1 SHARED=1

It gives:
F:\mingw\BIN\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: 
cannot open output file ..\..\lib\wxlua_msw28d_lua.dll: No such file or 
directory collect2: ld returned 1 exit status
mingw32-make[1]: *** [..\..\lib\wxlua_msw28d_lua.dll] Error 1
mingw32-make[1]: Leaving directory `F:/a_C/wxLua/modules/build/msw'
mingw32-make: *** [modules] Error 2


Since, I had similar results with modified (as your's but with gcc_dll)
makefile.gcc with a recent cvs, I didn't try it again.

There is no problem in SHARED=0 configuration.


--
Regards,
Hakki Dogusan

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

[Hakki D. <dog...@tr...>]

Hi,

Hakki Dogusan wrote:
> Hi,
> 
> John Labenski wrote:
>> Everything else seems great, I'm using VC 2003 and nmake.exe and both
>> release and debug work even with the wxStEditor lib!
>>
>> 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
>>
> [snip]
> 
> FYI,
> 
> (cvs 2006-12-17, wx2.8, winxp)
> 
> I tried with mingw:
> mingw32-make -fmakefile.gcc WX_VERSION=28 WX_MONOLITHIC=1 SHARED=1
> 
> It gives:
> F:\mingw\BIN\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: 
> cannot open output file ..\..\lib\wxlua_msw28d_lua.dll: No such file or 
> directory collect2: ld returned 1 exit status
> mingw32-make[1]: *** [..\..\lib\wxlua_msw28d_lua.dll] Error 1
> mingw32-make[1]: Leaving directory `F:/a_C/wxLua/modules/build/msw'
> mingw32-make: *** [modules] Error 2
> 
> 
> Since, I had similar results with modified (as your's but with gcc_dll)
> makefile.gcc with a recent cvs, I didn't try it again.
> 
> There is no problem in SHARED=0 configuration.
> 
> 

Funny...

I did a cvs update, then continue to compile..
Then send the above message.

Meanwhile, Francesco were committing his changes :)


Now building ends with:

(mingw32-make -fmakefile.gcc WX_VERSION=28 WX_MONOLITHIC=1 SHARED=1 
WX_SHARED=1 BUILD=release)


g++ -c -o gccdll\wxbind_dll_config.o
-I..\..\..\modules\wxbind\setup
-DHAVE_W32API_H
-D__WXMSW__
-IF:\WX\lib\gcc_dll\msw
-IF:\WX\include -DWXUSINGDLL
-O2  -I..\..\..\modules
-I.\..\..\..
-IF:\WX\contrib\include
-DWXMAKINGDLL_WXBIND
-MT
gccdll\wxbind_dll_config.o
-MFgccdll\wxbind_dll_config.o.d
-MD
../../wxbind/src/config.cpp
In file included from F:/WX/include/wx/wx.h:55,
                  from ../../wxbind/src/config.cpp:15:
F:/WX/include/wx/menu.h: In member function `#`qual_union_type' not 
supported by dump_decl#<declaration error>':
F:/WX/include/wx/menu.h:36: internal compiler error: in 
aggregate_value_p, at function.c:4264
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.mingw.org/bugs.shtml> for instructions.
mingw32-make[1]: *** [gccdll\wxbind_dll_config.o] Error 1
mingw32-make[1]: Leaving directory `F:/a_C/wxLua/modules/build/msw'
mingw32-make: *** [modules] Error 2




--
Regards,
Hakki Dogusan

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

[Hakki D. <dog...@tr...>]

Hi,

Francesco Montorsi wrote:
> Hakki Dogusan ha scritto:
>> Hi,
[snip]
>> Funny...
>>
>> I did a cvs update, then continue to compile..
>> Then send the above message.
>>
>> Meanwhile, Francesco were committing his changes :)
> right ;)
> 
> 
>> Now building ends with:
>>
>> (mingw32-make -fmakefile.gcc WX_VERSION=28 WX_MONOLITHIC=1 SHARED=1 
>> WX_SHARED=1 BUILD=release)
>>
>>
>> g++ -c -o gccdll\wxbind_dll_config.o
>> -I..\..\..\modules\wxbind\setup
>> -DHAVE_W32API_H
>> -D__WXMSW__
>> -IF:\WX\lib\gcc_dll\msw
>> -IF:\WX\include -DWXUSINGDLL
>> -O2  -I..\..\..\modules
>> -I.\..\..\..
>> -IF:\WX\contrib\include
>> -DWXMAKINGDLL_WXBIND
>> -MT
>> gccdll\wxbind_dll_config.o
>> -MFgccdll\wxbind_dll_config.o.d
>> -MD
>> .../../wxbind/src/config.cpp
>> In file included from F:/WX/include/wx/wx.h:55,
>>                   from ../../wxbind/src/config.cpp:15:
>> F:/WX/include/wx/menu.h: In member function `#`qual_union_type' not 
>> supported by dump_decl#<declaration error>':
>> F:/WX/include/wx/menu.h:36: internal compiler error: in 
>> aggregate_value_p, at function.c:4264
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <URL:http://www.mingw.org/bugs.shtml> for instructions.
>> mingw32-make[1]: *** [gccdll\wxbind_dll_config.o] Error 1
>> mingw32-make[1]: Leaving directory `F:/a_C/wxLua/modules/build/msw'
>> mingw32-make: *** [modules] Error 2
> hmmm, I'm going to test mingw ASAP; in the meanwhile I suggest you to:
> 
> 1) verify that you can compile&link a wx sample using that config

F:\wx\samples\minimal>mingw32-make -fmakefile.gcc BUILD=release SHARED=1 
MONOLITHIC=1

Builds OK.

> 2) do a make clean in wxLua and then retry.
> 

- did a make clean
- compiled with
F:\a_C\wxLua\build\msw>mingw32-make -fmakefile.gcc SHARED=1 
WX_MONOLITHIC=1 WX_SHARED=1 BUILD=release

- build stopped with ld error; couldn't find liblua5.1.a
- copied it manually to wxLua\lib\gcc_dll
- build finished OK.


Thanks.

> 
> Francesco
> 
> 

ps. I was reported this before but..
DependencyWalker shows following for wx.dll:

WX.DLL
- LUA5.1.DLL (lua_getfield)
- WXLUA_MSW28_WXBIND.DLL
--- WXLUA_MSW28_LUA.DLL
--- WXLUA_MSW28_WXLUA.DLL
--- WXMSW28_GCC_DS.DLL
- WXLUA_MSW28_WXLUA.DLL
--- WXLUA_MSW28_LUA.DLL
--- WXMSW28_GCC_DS.DLL
- WXMSW28_GCC_DS.DLL

Could it be possible to have only lua5.1.dll dependency
for wx.dll module configuration? Something like:

WX.DLL
- LUA5.1.DLL
- WXLUA_MSW28_WXBIND.DLL
--- LUA5.1.DLL
--- WXLUA_MSW28_WXLUA.DLL
--- WXMSW28_GCC_DS.DLL
- WXLUA_MSW28_WXLUA.DLL
--- LUA5.1.DLL
--- WXMSW28_GCC_DS.DLL
- WXMSW28_GCC_DS.DLL


--
Regards,
Hakki Dogusan

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

[Doug C. <dou...@gm...>]

Sunday, December 17, 2006, 8:46:45 AM, Hakki Dogusan wrote:

> It may be a radical change but, what about making
> lua as -weak- requirement?

> - if user already has lua installed use it, install only wxLua
> - otherwise build and install lua and wxLua

Would this make it possible to use, e.g., LuaJIT, or a patched Lua?
This would be a great feature, though another potential source of
problems, of course.

I build Lua from official sources using 'make mingw' and end up with a
library called lua51.dll -- wxLua seems to use a library name with an
extra dot. Can I provide the Lua library name to wxLua config?

e

-- 
Doug Currie
Londonderry, NH

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

[Hakki D. <dog...@tr...>]

Hi,

Doug Currie wrote:
> Sunday, December 17, 2006, 8:46:45 AM, Hakki Dogusan wrote:
> 
>> It may be a radical change but, what about making
>> lua as -weak- requirement?
> 
>> - if user already has lua installed use it, install only wxLua
>> - otherwise build and install lua and wxLua
> 
> Would this make it possible to use, e.g., LuaJIT, or a patched Lua?
> This would be a great feature, though another potential source of
> problems, of course.
> 
> I build Lua from official sources using 'make mingw' and end up with a
> library called lua51.dll -- wxLua seems to use a library name with an
> extra dot. Can I provide the Lua library name to wxLua config?
> 
> e
> 

I'm building lua with Code::Blocks. I don't remember why I'm
using this name :) Maybe it was talked at lua mail list.
Didn't notice the name of the dll generated by "make mingw".

There is following note on: http://luabinaries.luaforge.net/

# [04/Mar/2006]

     * Lua 5.1 - Release 1
       File names now use the suffix "5.1" instead of "51".



--
Regards,
Hakki Dogusan

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

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

Doug Currie ha scritto:
> Sunday, December 17, 2006, 8:46:45 AM, Hakki Dogusan wrote:
> 
>> It may be a radical change but, what about making
>> lua as -weak- requirement?
> 
>> - if user already has lua installed use it, install only wxLua
>> - otherwise build and install lua and wxLua
> 
> Would this make it possible to use, e.g., LuaJIT, or a patched Lua?
> This would be a great feature, though another potential source of
> problems, of course.
yes, checking for external lua headers/libs would allow to use patched 
luas with wxLua. And yes, it may be another potential source of problems :D

Francesco

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

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

Hakki Dogusan ha scritto:
> Hi,
> 
> Hakki Dogusan wrote:
>> Hi,
>>
>> John Labenski wrote:
>>> Everything else seems great, I'm using VC 2003 and nmake.exe and both
>>> release and debug work even with the wxStEditor lib!
>>>
>>> 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
>>>
>> [snip]
>>
>> FYI,
>>
>> (cvs 2006-12-17, wx2.8, winxp)
>>
>> I tried with mingw:
>> mingw32-make -fmakefile.gcc WX_VERSION=28 WX_MONOLITHIC=1 SHARED=1
>>
>> It gives:
>> F:\mingw\BIN\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: 
>> cannot open output file ..\..\lib\wxlua_msw28d_lua.dll: No such file or 
>> directory collect2: ld returned 1 exit status
>> mingw32-make[1]: *** [..\..\lib\wxlua_msw28d_lua.dll] Error 1
>> mingw32-make[1]: Leaving directory `F:/a_C/wxLua/modules/build/msw'
>> mingw32-make: *** [modules] Error 2
>>
>>
>> Since, I had similar results with modified (as your's but with gcc_dll)
>> makefile.gcc with a recent cvs, I didn't try it again.
>>
>> There is no problem in SHARED=0 configuration.
>>
>>
> 
> Funny...
> 
> I did a cvs update, then continue to compile..
> Then send the above message.
> 
> Meanwhile, Francesco were committing his changes :)
right ;)


> Now building ends with:
> 
> (mingw32-make -fmakefile.gcc WX_VERSION=28 WX_MONOLITHIC=1 SHARED=1 
> WX_SHARED=1 BUILD=release)
> 
> 
> g++ -c -o gccdll\wxbind_dll_config.o
> -I..\..\..\modules\wxbind\setup
> -DHAVE_W32API_H
> -D__WXMSW__
> -IF:\WX\lib\gcc_dll\msw
> -IF:\WX\include -DWXUSINGDLL
> -O2  -I..\..\..\modules
> -I.\..\..\..
> -IF:\WX\contrib\include
> -DWXMAKINGDLL_WXBIND
> -MT
> gccdll\wxbind_dll_config.o
> -MFgccdll\wxbind_dll_config.o.d
> -MD
> .../../wxbind/src/config.cpp
> In file included from F:/WX/include/wx/wx.h:55,
>                   from ../../wxbind/src/config.cpp:15:
> F:/WX/include/wx/menu.h: In member function `#`qual_union_type' not 
> supported by dump_decl#<declaration error>':
> F:/WX/include/wx/menu.h:36: internal compiler error: in 
> aggregate_value_p, at function.c:4264
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://www.mingw.org/bugs.shtml> for instructions.
> mingw32-make[1]: *** [gccdll\wxbind_dll_config.o] Error 1
> mingw32-make[1]: Leaving directory `F:/a_C/wxLua/modules/build/msw'
> mingw32-make: *** [modules] Error 2
hmmm, I'm going to test mingw ASAP; in the meanwhile I suggest you to:

1) verify that you can compile&link a wx sample using that config
2) do a make clean in wxLua and then retry.


Francesco

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

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

Hakki Dogusan ha scritto:
>> 2) do a make clean in wxLua and then retry.
>>
> 
> - did a make clean
> - compiled with
> F:\a_C\wxLua\build\msw>mingw32-make -fmakefile.gcc SHARED=1 
> WX_MONOLITHIC=1 WX_SHARED=1 BUILD=release
> 
> - build stopped with ld error; couldn't find liblua5.1.a
yes, that's related to my other thread "wxLua module"...

> - copied it manually to wxLua\lib\gcc_dll
> - build finished OK.
good


> ps. I was reported this before but..
> DependencyWalker shows following for wx.dll:
> 
> WX.DLL
> - LUA5.1.DLL (lua_getfield)
> - WXLUA_MSW28_WXBIND.DLL
> --- WXLUA_MSW28_LUA.DLL
> --- WXLUA_MSW28_WXLUA.DLL
> --- WXMSW28_GCC_DS.DLL
> - WXLUA_MSW28_WXLUA.DLL
> --- WXLUA_MSW28_LUA.DLL
> --- WXMSW28_GCC_DS.DLL
> - WXMSW28_GCC_DS.DLL
> 
> Could it be possible to have only lua5.1.dll dependency
> for wx.dll module configuration? Something like:
> 
> WX.DLL
> - LUA5.1.DLL
> - WXLUA_MSW28_WXBIND.DLL
> --- LUA5.1.DLL
> --- WXLUA_MSW28_WXLUA.DLL
> --- WXMSW28_GCC_DS.DLL
> - WXLUA_MSW28_WXLUA.DLL
> --- LUA5.1.DLL
> --- WXMSW28_GCC_DS.DLL
> - WXMSW28_GCC_DS.DLL
Absolutely: if we want to have wx.dll as a good Lua module we need to 
build instead of WXLUA_MSW28_WXLUA.DLL a LUA5.1.DLL. That's exactly what 
I say in "wxLua module" thread.

This has the side effect of replacing any user's lua5.1 library when 
doing "make install" but I think this is really not worth the extra the 
dependency which wx.dll currently has.

Francesco

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

[Hakki D. <dog...@tr...>]

Hi,

Francesco Montorsi wrote:
> Hakki Dogusan ha scritto:
[snip]
> 
>> ps. I was reported this before but..
>> DependencyWalker shows following for wx.dll:
>>
>> WX.DLL
>> - LUA5.1.DLL (lua_getfield)
>> - WXLUA_MSW28_WXBIND.DLL
>> --- WXLUA_MSW28_LUA.DLL
>> --- WXLUA_MSW28_WXLUA.DLL
>> --- WXMSW28_GCC_DS.DLL
>> - WXLUA_MSW28_WXLUA.DLL
>> --- WXLUA_MSW28_LUA.DLL
>> --- WXMSW28_GCC_DS.DLL
>> - WXMSW28_GCC_DS.DLL
>>
>> Could it be possible to have only lua5.1.dll dependency
>> for wx.dll module configuration? Something like:
>>
>> WX.DLL
>> - LUA5.1.DLL
>> - WXLUA_MSW28_WXBIND.DLL
>> --- LUA5.1.DLL
>> --- WXLUA_MSW28_WXLUA.DLL
>> --- WXMSW28_GCC_DS.DLL
>> - WXLUA_MSW28_WXLUA.DLL
>> --- LUA5.1.DLL
>> --- WXMSW28_GCC_DS.DLL
>> - WXMSW28_GCC_DS.DLL
> Absolutely: if we want to have wx.dll as a good Lua module we need to 
> build instead of WXLUA_MSW28_WXLUA.DLL a LUA5.1.DLL. That's exactly what 
> I say in "wxLua module" thread.
> 

Yes. You did. Sorry.

> This has the side effect of replacing any user's lua5.1 library when 
> doing "make install" but I think this is really not worth the extra the 
> dependency which wx.dll currently has.
> 
> Francesco
> 


It may be a radical change but, what about making
lua as -weak- requirement?

- if user already has lua installed use it, install only wxLua
- otherwise build and install lua and wxLua

ps. I never use "make install" on windows.


--
Regards,
Hakki Dogusan

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

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

Hakki Dogusan ha scritto:
>> This has the side effect of replacing any user's lua5.1 library when 
>> doing "make install" but I think this is really not worth the extra the 
>> dependency which wx.dll currently has.
>>
>> Francesco
>>
> 
> 
> It may be a radical change but, what about making
> lua as -weak- requirement?
well, lua is not exactly a "requirement" for wxLua currently: that is, 
wxLua already have lua sources inside it so that it does not require an 
external lua library ;)

> - if user already has lua installed use it, install only wxLua
> - otherwise build and install lua and wxLua
this may be a Good Thing; however I'm unsure; it would add a lot of 
complexity to the build system because if we want to use the system-wide 
lua then we should also avoid to include the lua headers which we have 
in "wxLua\modules\lua" in favour of the system-wide headers (since it's 
not 100% granted that the two set of headers are identic - and this 
could lead to weird build errors).

It's so simple to just overwrite the system-wide install of lua that I'd 
prefer that way (provided that we document that clearly in the readme) ;)

> ps. I never use "make install" on windows.
nor do I; the overwriting matter is unix-only in fact.

Thanks,
Francesco