wxlua-users

[wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

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

I have rewritten the coroutine code so that we do not have to replace
luaE_newthread and luaE_freethread by pushing the wxLuaStateRefData
into the registry table.

Hopefully this will make using wxLua as a lua module using require
much easier... of course the build files have to sorted out.

Regards,
    John Labenski

Re: [wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

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

John Labenski ha scritto:
> I have rewritten the coroutine code so that we do not have to replace
> luaE_newthread and luaE_freethread by pushing the wxLuaStateRefData
> into the registry table.
good work!

> 
> Hopefully this will make using wxLua as a lua module using require
> much easier... of course the build files have to sorted out.
I'll reorganize the bakefiles tonight ;)

With bakefile 0.2.1 we are very very near to have all functionalities we 
need in the "official" bakefile. In fact, the only thing which makes us 
depend on a patched bakefile currently is that we want to:

  1) use wxPresets and all logic they contain
  2) have WX_DEBUG=0/1 and WX_UNICODE replaced by BUILD=debug/release 
and UNICODE option names

if we remove "feature" #2 then we can use bakefile 0.2.1
if we don't, hopefully Vaclav will apply my patch for bakefile 0.2.2 
(I'm pinging him about that patch since a long time now).

Is there any other build problem which I should solve this evening ?

Francesco

Re: [wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

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

On 12/6/06, Francesco Montorsi <f18...@ya...> wrote:
> John Labenski ha scritto:
> > I have rewritten the coroutine code so that we do not have to replace
> > luaE_newthread and luaE_freethread by pushing the wxLuaStateRefData
> > into the registry table.
> good work!
>
> >
> > Hopefully this will make using wxLua as a lua module using require
> > much easier... of course the build files have to sorted out.
> I'll reorganize the bakefiles tonight ;)
>
> With bakefile 0.2.1 we are very very near to have all functionalities we
> need in the "official" bakefile. In fact, the only thing which makes us
> depend on a patched bakefile currently is that we want to:
>
>   1) use wxPresets and all logic they contain
>   2) have WX_DEBUG=0/1 and WX_UNICODE replaced by BUILD=debug/release
> and UNICODE option names
>
> if we remove "feature" #2 then we can use bakefile 0.2.1
> if we don't, hopefully Vaclav will apply my patch for bakefile 0.2.2
> (I'm pinging him about that patch since a long time now).

Hopefully, soon. :)

Is the bakefile on the wxLua website the same one you're using
(htdocs/bakefile/frm-bakefile.tar.gz). I haven't tried it yet, since
this would be the first time I'd need it. If not could you update it
if it's not too much trouble?

> Is there any other build problem which I should solve this evening ?

I don't think so. I dunno what you want to do about naming the lua.exe
and lua.dll. Do we put wx in it somewhere since some linux
distributions have lua packages and we don't want to overwrite it for
"make install" even though it's identical?

Thanks,
    John Labenski

Re: [wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

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

ps. Yes there is something that would be nice to have in the build files.

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
>From modules_mod_wxlua.dsp

!ELSEIF  "$(CFG)" == "mod_wxlua - Win32 DLL Debug Monolithic"
!ELSEIF  "$(CFG)" == "mod_wxlua - Win32 DLL Debug Multilib"
!ELSEIF  "$(CFG)" == "mod_wxlua - Win32 Debug Monolithic"
!ELSEIF  "$(CFG)" == "mod_wxlua - Win32 Debug Multilib"

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.

I hope that is easy to do, thanks
     John Labenski



On 12/6/06, John Labenski <jla...@gm...> wrote:
> On 12/6/06, Francesco Montorsi <f18...@ya...> wrote:
> > John Labenski ha scritto:
> > > I have rewritten the coroutine code so that we do not have to replace
> > > luaE_newthread and luaE_freethread by pushing the wxLuaStateRefData
> > > into the registry table.
> > good work!
> >
> > >
> > > Hopefully this will make using wxLua as a lua module using require
> > > much easier... of course the build files have to sorted out.
> > I'll reorganize the bakefiles tonight ;)
> >
> > With bakefile 0.2.1 we are very very near to have all functionalities we
> > need in the "official" bakefile. In fact, the only thing which makes us
> > depend on a patched bakefile currently is that we want to:
> >
> >   1) use wxPresets and all logic they contain
> >   2) have WX_DEBUG=0/1 and WX_UNICODE replaced by BUILD=debug/release
> > and UNICODE option names
> >
> > if we remove "feature" #2 then we can use bakefile 0.2.1
> > if we don't, hopefully Vaclav will apply my patch for bakefile 0.2.2
> > (I'm pinging him about that patch since a long time now).
>
> Hopefully, soon. :)
>
> Is the bakefile on the wxLua website the same one you're using
> (htdocs/bakefile/frm-bakefile.tar.gz). I haven't tried it yet, since
> this would be the first time I'd need it. If not could you update it
> if it's not too much trouble?
>
> > Is there any other build problem which I should solve this evening ?
>
> I don't think so. I dunno what you want to do about naming the lua.exe
> and lua.dll. Do we put wx in it somewhere since some linux
> distributions have lua packages and we don't want to overwrite it for
> "make install" even though it's identical?
>
> Thanks,
>     John Labenski
>

Re: [wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

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

John Labenski ha scritto:
> ps. Yes there is something that would be nice to have in the build files.
> 
> 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
>>From modules_mod_wxlua.dsp
> 
> !ELSEIF  "$(CFG)" == "mod_wxlua - Win32 DLL Debug Monolithic"
> !ELSEIF  "$(CFG)" == "mod_wxlua - Win32 DLL Debug Multilib"
> !ELSEIF  "$(CFG)" == "mod_wxlua - Win32 Debug Monolithic"
> !ELSEIF  "$(CFG)" == "mod_wxlua - Win32 Debug Multilib"
> 
> 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.

Francesco

Re: [wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

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

Francesco Montorsi ha scritto:
> John Labenski ha scritto:
>> ps. Yes there is something that would be nice to have in the build files.
>>
>> 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
>> >From modules_mod_wxlua.dsp
>>
>> !ELSEIF  "$(CFG)" == "mod_wxlua - Win32 DLL Debug Monolithic"
>> !ELSEIF  "$(CFG)" == "mod_wxlua - Win32 DLL Debug Multilib"
>> !ELSEIF  "$(CFG)" == "mod_wxlua - Win32 Debug Monolithic"
>> !ELSEIF  "$(CFG)" == "mod_wxlua - Win32 Debug Multilib"
>>
>> 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...

Francesco

Re: [wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

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

On 12/8/06, Francesco Montorsi <f18...@ya...> 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

Re: [wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

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

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 <jla...@gm...> wrote:
> On 12/8/06, Francesco Montorsi <f18...@ya...> 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
>

[wxlua-users] build system update (was Re: wxLua now uses an unmodified copy of lua 5.1.1)

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

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 <jla...@gm...> wrote:
>> On 12/8/06, Francesco Montorsi <f18...@ya...> 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

Re: [wxlua-users] build system update (was Re: wxLua now uses an unmodified copy of lua 5.1.1)

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

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.

>   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?

> 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 know what to do about this, but I think it is bad form to
overwrite the lua executables installed by a rpm or deb package.

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

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

Thanks,
    John Labenski

Re: [wxlua-users] build system update (was Re: wxLua now uses an unmodified copy of lua 5.1.1)

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

John Labenski wrote:
>
>
> 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.
>   
So i think you want

wxlua_msw28d_wxbind.lib  Renamed to wxmsw28d_wxbind.lib.

In the last  i see now wxlua, this is why we once decide to use wxlua_ 
as a sort of name space.
I am not sure why wxCode prefers it different. I understand for one lib 
project there is no confusion.
But for project with several modules, i don't like it. Like in wxArt2d i 
have 16 libraries coming from 16 modules.
If there is no name space at the start like wxart2d_mswd28d_curves.lib 
wxart2d_mswd28d_kbool.lib etc. i think it will be harder to find out 
what library comes from what after installation.
Looking at  the wxWidgets naming , i also see  wxbase28.lib, next to 
wxmsw28_core and wxmsw28_stc, i don't see the logic.
I only see "wx" as common namespace, why did they not use wxmsw in front 
of all??
Anyway it seems that all contrib stuff is in the from wxmsw28_nameofcontrib.
So looking at it like that maybe we should have:

wxmsw28d_wxlua_lua.lib
wxmsw28d_wxlua_bind.lib
wxmsw28d_wxlua_debug.lib
wxmsw28d_wxlua_socket.lib
etc.

or if oke:

wxmsw28d_lua_lua.lib
wxmsw28d_lua_bind.lib
wxmsw28d_lua_debug.lib
wxmsw28d_lua_socket.lib

In the end for wxstedit, it is not:

wxmsw28d_wxstedit.lib

but:

wxmsw28d_stedit.lib

So only one time the wx in it.
Like:

wxnamespace+platform+version_libraryset_specificModule.lib

What do we think is best?

Klaas

Re: [wxlua-users] build system update (was Re: wxLua now uses an unmodified copy of lua 5.1.1)

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

Hi,

klaas.holwerda wrote:
[snip]
> 
> wxmsw28d_wxlua_lua.lib
> wxmsw28d_wxlua_bind.lib
> wxmsw28d_wxlua_debug.lib
> wxmsw28d_wxlua_socket.lib
> etc.
> 

I like that.

Relatively for the shared configuration:

wxmsw28_gcc_"vendor"_wxlua_lua.dll
wxmsw28_gcc_"vendor"_wxlua_bind.dll
wxmsw28u_gcc_"vendor"_wxlua_lua.dll



--
Regards,
Hakki Dogusan

Re: [wxlua-users] build system update (was Re: wxLua now uses an unmodified copy of lua 5.1.1)

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

klaas.holwerda ha scritto:
> John Labenski wrote:
>>
>> 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.
>>   
> So i think you want
> 
> wxlua_msw28d_wxbind.lib  Renamed to wxmsw28d_wxbind.lib.
> 
> In the last  i see now wxlua, this is why we once decide to use wxlua_ 
> as a sort of name space.
> I am not sure why wxCode prefers it different. 
it's not a preference - just a "bug". Definitively the <wxlike-lib> tag 
should take in account a prefix as other wxlike-* tags do.

I've updated the wxpresets patch which I've submitted to wxWidgets with 
a wxlike-lib tag which supports the prefix so that hopefully it won't be 
a problem anymore soon.

>I understand for one lib 
> project there is no confusion.
> But for project with several modules, i don't like it. Like in wxArt2d i 
> have 16 libraries coming from 16 modules.
> If there is no name space at the start like wxart2d_mswd28d_curves.lib 
> wxart2d_mswd28d_kbool.lib etc. i think it will be harder to find out 
> what library comes from what after installation.
I agree

> Looking at  the wxWidgets naming , i also see  wxbase28.lib, next to 
> wxmsw28_core and wxmsw28_stc, i don't see the logic.
there's a logic, really ;)

> I only see "wx" as common namespace, why did they not use wxmsw in front 
> of all??
because some of wx libraries are not port-dependent. E.g. the wxBase 
library does not uses different sources when compiled as wxMSW and 
others when compiled as wxGTK.

> Anyway it seems that all contrib stuff is in the from wxmsw28_nameofcontrib.
> So looking at it like that maybe we should have:
> 
> wxmsw28d_wxlua_lua.lib
> wxmsw28d_wxlua_bind.lib
> wxmsw28d_wxlua_debug.lib
> wxmsw28d_wxlua_socket.lib
> etc.
hmmm, I don't see any great advantage over current naming, except that 
this is backward-incompatible for all ours wxLua users which should 
probably need to update their makefiles/project files without any real 
need (wxlike-lib tag must be fixed, not our naming rules).

Francesco

Re: [wxlua-users] build system update (was Re: wxLua now uses an unmodified copy of lua 5.1.1)

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

These warnings are back, I'm pretty sure I didn't get them a week ago
and I don't understand what the problem could be. I'm using wxWidgets
2.6 from CVS and MS Visual Studio 6.

--------------------Configuration: mod_verbatimlua - Win32 Debug
Multilib--------------------
Compiling...
lapi.c
...
lzio.c
Generating Code...
Creating library...
--------------------Configuration: mod_wxlua - Win32 Debug
Multilib--------------------
Compiling...
dummy.cpp
Compiling...
wxlbind.cpp
wxlcallb.cpp
wxlstate.cpp
Generating Code...
Creating library...
--------------------Configuration: mod_wxbind - Win32 Debug
Multilib--------------------
Compiling...
dummy.cpp
Compiling...
appframe.cpp
...
xml.cpp
Generating Code...
Creating library...
wxlua_msw26d_lua.lib(lapi.obj) : warning LNK4006: _lua_ident already
defined in wxlua_msw26d_wxlua.lib(lapi.obj); second definition ignored
wxlua_msw26d_lua.lib(lapi.obj) : warning LNK4006: _luaA_pushobject
already defined in wxlua_msw26d_wxlua.lib(lapi.obj); second definition
ignored
wxlua_msw26d_lua.lib(lzio.obj) : warning LNK4006: _luaZ_openspace
already defined in wxlua_msw26d_wxlua.lib(lzio.obj); second definition
ignored
...
--------------------Configuration: mod_wxbindstc - Win32 Debug
Multilib--------------------
Compiling...
dummy.cpp
Compiling...
stc.cpp
wxstc_bind.cpp
Generating Code...
Creating library...
wxlua_msw26d_lua.lib(lapi.obj) : warning LNK4006: _lua_ident already
defined in wxlua_msw26d_wxlua.lib(lapi.obj); second definition ignored
wxlua_msw26d_lua.lib(lapi.obj) : warning LNK4006: _luaA_pushobject
already defined in wxlua_msw26d_wxlua.lib(lapi.obj); second definition
ignored

and so on for the other libs. Any ideas why this is happening again? I
can't understand why the const char lua_ident[] = {...} inside of
lapi.c only (not in header at all) could possibly have a problem since
mod_wxbind Debug Multilib doesn't link to anything!

On 12/10/06, Francesco Montorsi <f18...@ya...> wrote:
> klaas.holwerda ha scritto:
> > John Labenski wrote:
> >>
> >> 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.
> >>
> > So i think you want
> > wxlua_msw28d_wxbind.lib  Renamed to wxmsw28d_wxbind.lib.

Yes, but I like wxmsw28d_wxlua_wxbind.lib

> > In the last  i see now wxlua, this is why we once decide to use wxlua_
> > as a sort of name space.
> > I am not sure why wxCode prefers it different.
> it's not a preference - just a "bug". Definitively the <wxlike-lib> tag
> should take in account a prefix as other wxlike-* tags do.

Maybe an additional <wxlike-prefix-lib> that has the prefix could be
added. The <wxlike-lib> code is pretty small so it might not be too
much bloat. See below, that idea sounds pretty good and very simple.

> > Anyway it seems that all contrib stuff is in the from wxmsw28_nameofcontrib.
> > So looking at it like that maybe we should have:
> >
> > wxmsw28d_wxlua_lua.lib
> > wxmsw28d_wxlua_bind.lib
> > wxmsw28d_wxlua_debug.lib
> > wxmsw28d_wxlua_socket.lib
> > etc.
> hmmm, I don't see any great advantage over current naming, except that
> this is backward-incompatible for all ours wxLua users which should
> probably need to update their makefiles/project files without any real
> need (wxlike-lib tag must be fixed, not our naming rules).

I don't think we have to worry about backwards compatibility too much.
We have a small user base and hopefully things will be settled once
and for all after this.

I DO like this idea and think it's just as well. I'd keep the wx in
the second name though to be clear about what the lib is really for
since wxluadebug/socket are not generic debug/socket libs, but only
work with wxlua.

wxlua_msw26d_wxlua_lua.lib
wxlua_msw26d_wxlua_wxbind.lib
wxlua_msw26d_wxlua_wxbindstc.lib
wxlua_msw26d_wxlua_wxlua.lib
wxlua_msw26d_wxlua_wxluadebug.lib
wxlua_msw26d_wxlua_wxluasocket.lib

In any case, do whatever you think is best Francesco.

Was there anything else I've missed?

Thanks,
    John Labenski

ps. The precompiled headers are GREAT! I can't really tell much of a
difference in MSVC6, but I was thinking about how we could do it and
wanted to ask if you knew how, but thought it might be too much work.

Re: [wxlua-users] build system update (was Re: wxLua now uses an unmodified copy of lua 5.1.1)

[Klaas H. <db...@nl...>]

John Labenski wrote:

> 
>>>Anyway it seems that all contrib stuff is in the from wxmsw28_nameofcontrib.
>>>So looking at it like that maybe we should have:
>>>
>>>wxmsw28d_wxlua_lua.lib
>>>wxmsw28d_wxlua_bind.lib
>>>wxmsw28d_wxlua_debug.lib
>>>wxmsw28d_wxlua_socket.lib
>>>etc.
>>
>>hmmm, I don't see any great advantage over current naming, except that
>>this is backward-incompatible for all ours wxLua users which should
>>probably need to update their makefiles/project files without any real
>>need (wxlike-lib tag must be fixed, not our naming rules).

Agreed and for me the current wxlua way is just fine. I just got confused by wxCode and its naming of libs.
But as you say it should be changed.

All in all i think i still like this a little more:

wxlua_msw28d_debug.lib

compared to:

wxmsw28d_wxlua_debug.lib

The namespace in the beginning is easier when it comes to sorting (ls or dir will show them grouped ).

> I DO like this idea and think it's just as well. I'd keep the wx in
> the second name though to be clear about what the lib is really for
> since wxluadebug/socket are not generic debug/socket libs, but only
> work with wxlua.
> 
> wxlua_msw26d_wxlua_lua.lib
> wxlua_msw26d_wxlua_wxbind.lib
> wxlua_msw26d_wxlua_wxbindstc.lib
> wxlua_msw26d_wxlua_wxlua.lib
> wxlua_msw26d_wxlua_wxluadebug.lib
> wxlua_msw26d_wxlua_wxluasocket.lib

But this seconds wxlua has the same goal as the first is it not?
So why add it twice?
I looks like the current situation in wxLua is not a problem ;-)

> 
> In any case, do whatever you think is best Francesco.

Yep.

>> ps. The precompiled headers are GREAT! I can't really tell much of a
> difference in MSVC6, but I was thinking about how we could do it and
> wanted to ask if you knew how, but thought it might be too much work.

Well in wxArt2D we have it working. The idea is this:

// our own pre compiled header file.
#include "general/include/a2dprec.h"

#ifdef __GNUG__
     #pragma implementation "artglob.h"
#endif

#ifdef __BORLANDC__
     #pragma hdrstop
#endif

#ifndef WX_PRECOMP
     #include "wx/wx.h"
#endif

----------------------

/*! \file general/include/a2dprec.h

     Licence: wxWidgets License

     RCS-ID: $Id: a2dprec.h,v 1.2 2005/08/10 21:10:48 titato Exp $
*/

#include "wx/wxprec.h"

#ifdef WX_PRECOMP

#include <wx/mstream.h>
#include <wx/tokenzr.h>
#include "wxart2d.h"

#endif // WX_PRECOMP


And at last have the precompiled header flags for the compiler.
And the central dummy.cpp file used in each module.

Not that complicated.

Klaas

-- 
Unclassified

Re: [wxlua-users] build system update (was Re: wxLua now uses an unmodified copy of lua 5.1.1)

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

Klaas Holwerda ha scritto:
> All in all i think i still like this a little more:
> 
> wxlua_msw28d_debug.lib
> 
> compared to:
> 
> wxmsw28d_wxlua_debug.lib
> 
> The namespace in the beginning is easier when it comes to sorting (ls or dir will show them grouped ).
I agree, I like to see "wxlua" as a prefix instead of having it in the middle.


>>> ps. The precompiled headers are GREAT! I can't really tell much of a
>> difference in MSVC6, but I was thinking about how we could do it and
>> wanted to ask if you knew how, but thought it might be too much work.
> 
> Well in wxArt2D we have it working. The idea is this:
> 
> // our own pre compiled header file.
> #include "general/include/a2dprec.h"
> 
> #ifdef __GNUG__
>      #pragma implementation "artglob.h"
> #endif
> 
> #ifdef __BORLANDC__
>      #pragma hdrstop
> #endif
> 
> #ifndef WX_PRECOMP
>      #include "wx/wx.h"
> #endif
> 
well, I'd say that we should infact have a wxluaprec.h file and then put all 
possible headers there and all other unnecessary #include directives into the 
WX_PRECOMP block.

I think we should also remove these blocks:

#if defined(__GNUG__) && !defined(NO_GCC_PRAGMA)
     #pragma implementation "wxlstate.h"
#endif

GCC does not use it anymore since a long time and they can only give problems...


Francesco

[wxlua-users] LNK4006 (was Re: build system update)

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

Hi,

John Labenski ha scritto:
> These warnings are back, I'm pretty sure I didn't get them a week ago
> and I don't understand what the problem could be. I'm using wxWidgets
> 2.6 from CVS and MS Visual Studio 6.
I get them also with MS VisualStudio 7.1 with wxMSW 2.8...


> wxlua_msw26d_lua.lib(lapi.obj) : warning LNK4006: _lua_ident already
> defined in wxlua_msw26d_wxlua.lib(lapi.obj); second definition ignored
...
> 
> and so on for the other libs. Any ideas why this is happening again?
I've searched the wxlua-users mailing list but I couldn't find any reference 
(except in the very latest mails) to LNK4006 warnings - did we ever get them before?

> I
> can't understand why the const char lua_ident[] = {...} inside of
> lapi.c only (not in header at all) could possibly have a problem since
> mod_wxbind Debug Multilib doesn't link to anything!
I can't understand that too. I've checked and unless my eyes are lying to me, 
all the DSP are using the same build settings.
I've searched the net but I couldn't find any good hint. It's strange: the 
linker shouldn't run at all when creating a static lib!


>>> In the last  i see now wxlua, this is why we once decide to use wxlua_
>>> as a sort of name space.
>>> I am not sure why wxCode prefers it different.
>> it's not a preference - just a "bug". Definitively the <wxlike-lib> tag
>> should take in account a prefix as other wxlike-* tags do.
> 
> Maybe an additional <wxlike-prefix-lib> that has the prefix could be
> added. The <wxlike-lib> code is pretty small so it might not be too
> much bloat. See below, that idea sounds pretty good and very simple.
sure, adding a new tag like <wxlike-prefix-lib> would be feasible but I hope 
that it won't even be needed - as soon as wx2.8.0 will be released I hope to get 
the wxpresets patch applied (and it contains a working wxlike-lib tag with 
prefix support).

> 
>>> Anyway it seems that all contrib stuff is in the from wxmsw28_nameofcontrib.
>>> So looking at it like that maybe we should have:
>>>
>>> wxmsw28d_wxlua_lua.lib
>>> wxmsw28d_wxlua_bind.lib
>>> wxmsw28d_wxlua_debug.lib
>>> wxmsw28d_wxlua_socket.lib
>>> etc.
>> hmmm, I don't see any great advantage over current naming, except that
>> this is backward-incompatible for all ours wxLua users which should
>> probably need to update their makefiles/project files without any real
>> need (wxlike-lib tag must be fixed, not our naming rules).
> 
> I don't think we have to worry about backwards compatibility too much.
> We have a small user base and hopefully things will be settled once
> and for all after this.
> 
> I DO like this idea and think it's just as well. I'd keep the wx in
> the second name though to be clear about what the lib is really for
> since wxluadebug/socket are not generic debug/socket libs, but only
> work with wxlua.
> 
> wxlua_msw26d_wxlua_lua.lib
> wxlua_msw26d_wxlua_wxbind.lib
> wxlua_msw26d_wxlua_wxbindstc.lib
> wxlua_msw26d_wxlua_wxlua.lib
> wxlua_msw26d_wxlua_wxluadebug.lib
> wxlua_msw26d_wxlua_wxluasocket.lib
sorry but I don't understand why should we repeat "wxlua" twice in the name of 
the libraries: if there's 1 "wxlua" prefix it seems quite clear to me that the 
debug/sockets libs are not "generic" but wxlua-only.

> 
> In any case, do whatever you think is best Francesco.
sorry but I don't see what's wrong with current naming - I'd just keep it as in 
current way...

> ps. The precompiled headers are GREAT! I can't really tell much of a
> difference in MSVC6, but I was thinking about how we could do it and
> wanted to ask if you knew how, but thought it might be too much work.
glad to know they were appreciated - however to speedup even more the 
compilation of wxLua our headers should include a wxLua PCH, just as Klaas 
suggests (see other mail).


Francesco

Re: [wxlua-users] LNK4006 (was Re: build system update)

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

Francesco Montorsi wrote:
> Hi,
>
> John Labenski ha scritto:
>   
>> These warnings are back, I'm pretty sure I didn't get them a week ago
>> and I don't understand what the problem could be. I'm using wxWidgets
>> 2.6 from CVS and MS Visual Studio 6.
>>     
> I get them also with MS VisualStudio 7.1 with wxMSW 2.8...
>   
7.10.3077

I did a complete new wxLua checkout first. And i thought i did not see 
those warning.
But removed all object files and lib files and build again, no such 
warnings!
This is using nmake not IDE.
>> wxlua_msw26d_wxlua_wxluadebug.lib
>> wxlua_msw26d_wxlua_wxluasocket.lib
>>     
> sorry but I don't understand why should we repeat "wxlua" twice in the name of 
> the libraries: if there's 1 "wxlua" prefix it seems quite clear to me that the 
> debug/sockets libs are not "generic" but wxlua-only.
>   
Same here, to me its fine as is.
>   
>> In any case, do whatever you think is best Francesco.
>>     
> sorry but I don't see what's wrong with current naming - I'd just keep it as in 
> current way...
>   
Agreed.
>   
>> ps. The precompiled headers are GREAT! I can't really tell much of a
>> difference in MSVC6, but I was thinking about how we could do it and
>> wanted to ask if you knew how, but thought it might be too much work.
>>     
> glad to know they were appreciated - however to speedup even more the 
> compilation of wxLua our headers should include a wxLua PCH, just as Klaas 
> suggests (see other mail).
>   
If help is need, let me know. But first i need to get wxArt2D going with 
the new bin dir, lib names etc.


regards,

Klaas

Re: [wxlua-users] build system update (was Re: wxLua now uses an unmodified copy of lua 5.1.1)

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

On 12/11/06, klaas.holwerda <kho...@xs...> wrote:
> Francesco Montorsi wrote:
> > Klaas Holwerda ha scritto:
> > I agree, I like to see "wxlua" as a prefix instead of having it in the middle.

Ok, about the suggestions I made, I forgot to remove the wxlua_
prefix, I meant wxgtk2ud_wxlua_XXX.lib, but anyway, just ignore all
that. having wxlua_wxgtk2ud_XXX.lib is just fine by me.

> > I think we should also remove these blocks:
> >
> > #if defined(__GNUG__) && !defined(NO_GCC_PRAGMA)
> >      #pragma implementation "wxlstate.h"
> > #endif
> >
> > GCC does not use it anymore since a long time and they can only give problems...
> >
> Very right, i still needed to that.

Ok, I can do this. I'm going through all the code and hopefully once
and for all give things good names now that I have a much better
understanding of everything.

-John Labenski

Re: [wxlua-users] build system update (was Re: wxLua now uses an unmodified copy of lua 5.1.1)

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

John Labenski ha scritto:
>>> I think we should also remove these blocks:
>>>
>>> #if defined(__GNUG__) && !defined(NO_GCC_PRAGMA)
>>>      #pragma implementation "wxlstate.h"
>>> #endif
>>>
>>> GCC does not use it anymore since a long time and they can only give problems...
>>>
>> Very right, i still needed to that.
> 
> Ok, I can do this. I'm going through all the code and hopefully once
> and for all give things good names now that I have a much better
> understanding of everything.
great !

Before 2.8.0.0 release I hope to be able to put the PCH compilation in a 
better shape (i.e. have faster builds) by adding a wxluaprec.h file and 
a "wxlua.h" which include all wxLua headers so that ours PCH files will 
have also wxLua code precompiled (currently precompilation affects only 
wx headers).

Francesco

Re: [wxlua-users] build system update (was Re: wxLua now uses an unmodified copy of lua 5.1.1)

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

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

[wxlua-users] wxLua module (was Re: build system update)

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

Francesco Montorsi ha scritto:
>   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?
Ok, I now remember why we decided to call it lua5.1; the wx.dll module we build 
from modules\luamodule is coinceived to be used as any other Lua module.  I.e. 
it must be linked against a DLL/DSO named "lua5.1" not "wxlua_msw28_lua".

So, I think we have no other choice that making our "lua" module build a library 
named lua5.1 and then install it in standard paths, eventually overwriting the 
preexisting one.

This should not be a big problem since the name is versioned and we're using 
vanilla lua now. It may just be a problem if someone modified lua and thus has 
in system paths a custom version (but this is a bad practice anyway; that user 
should consider to name its custom library in some other way).

Do you agree with this change?

Once we get this up and running I think we should also

   1) add our "wx" module to this list:

       http://lua-users.org/wiki/LuaBinaryModules (look at the end)

   2) publish in the next release a single .ZIP download which contains only the 
wxLua+wxWidgets DLLs + wx.dll module; so that users could just unzip them and 
start using wx.dll module as for any other lua module.


Francesco

Re: [wxlua-users] wxLua module (was Re: build system update)

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

On 12/17/06, Francesco Montorsi <f18...@ya...> wrote:
> Francesco Montorsi ha scritto:
> >   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?
> Ok, I now remember why we decided to call it lua5.1; the wx.dll module we build
> from modules\luamodule is coinceived to be used as any other Lua module.  I.e.
> it must be linked against a DLL/DSO named "lua5.1" not "wxlua_msw28_lua".
>
> So, I think we have no other choice that making our "lua" module build a library
> named lua5.1 and then install it in standard paths, eventually overwriting the
> preexisting one.
>
> This should not be a big problem since the name is versioned and we're using
> vanilla lua now. It may just be a problem if someone modified lua and thus has
> in system paths a custom version (but this is a bad practice anyway; that user
> should consider to name its custom library in some other way).
>
> Do you agree with this change?

Can we test in configure if the lua and lua devel packages are
installed and use those sources? Too much work? I guess it would work
like wxWidgets use of the jpeg, png, etc libs. I don't know how to do
any of this. :(

> Once we get this up and running I think we should also
>
>    1) add our "wx" module to this list:
>
>        http://lua-users.org/wiki/LuaBinaryModules (look at the end)
>
>    2) publish in the next release a single .ZIP download which contains only the
> wxLua+wxWidgets DLLs + wx.dll module; so that users could just unzip them and
> start using wx.dll module as for any other lua module.

This would be great, I can compile them with MSVC 6 which I think
should be the best since it generates the smallest binaries. Can mingw
use dlls use VC dlls?

Regards,
    John Labenski

Re: [wxlua-users] wxLua module (was Re: build system update)

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

John Labenski ha scritto:
> On 12/17/06, Francesco Montorsi <f18...@ya...> wrote:
>> Francesco Montorsi ha scritto:
>>>   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?
>> Ok, I now remember why we decided to call it lua5.1; the wx.dll module we build
>> from modules\luamodule is coinceived to be used as any other Lua module.  I.e.
>> it must be linked against a DLL/DSO named "lua5.1" not "wxlua_msw28_lua".
>>
>> So, I think we have no other choice that making our "lua" module build a library
>> named lua5.1 and then install it in standard paths, eventually overwriting the
>> preexisting one.
>>
>> This should not be a big problem since the name is versioned and we're using
>> vanilla lua now. It may just be a problem if someone modified lua and thus has
>> in system paths a custom version (but this is a bad practice anyway; that user
>> should consider to name its custom library in some other way).
>>
>> Do you agree with this change?
> 
> Can we test in configure if the lua and lua devel packages are
> installed and use those sources? Too much work? I guess it would work
> like wxWidgets use of the jpeg, png, etc libs. I don't know how to do
> any of this. :(
It wouldn't be much difficult from the build-system POV.
The problem may be related to the way we include the lua headers:

#include "lua/include/lua.h"

I'll try to implement the check and then set a wxUSE_CUSTOM_LUA 
preprocessor symbol if a usable lua 5.1 is found. The header inclusion 
would then be modified:

#if wxUSE_CUSTOM_LUA
    #include "lua.h"
#else
    #include "lua/include/lua.h"
#endif

otherwise we could also simply add the "modules/lua/include" path to the 
paths given to compiler so that we could just use:

#include "lua.h"

all the times.


>> Once we get this up and running I think we should also
>>
>>    1) add our "wx" module to this list:
>>
>>        http://lua-users.org/wiki/LuaBinaryModules (look at the end)
>>
>>    2) publish in the next release a single .ZIP download which contains only the
>> wxLua+wxWidgets DLLs + wx.dll module; so that users could just unzip them and
>> start using wx.dll module as for any other lua module.
> 
> This would be great, I can compile them with MSVC 6 which I think
> should be the best since it generates the smallest binaries. Can mingw
> use dlls use VC dlls?
yes, absolutely.

Generating them with MSVC6 is probably the best choice also because that 
way they probably avoid dependencies on newer MSVC dlls which are 
sometimes missing on old systems (I suspect that the DLL I build using 
MSVC7.1 requires msvc71.dll or something like that).

Francesco

Re: [wxlua-users] wxLua module (was Re: build system update)

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

Francesco Montorsi ha scritto:
> John Labenski ha scritto:
>> Can we test in configure if the lua and lua devel packages are
>> installed and use those sources? Too much work? I guess it would work
>> like wxWidgets use of the jpeg, png, etc libs. I don't know how to do
>> any of this. :(
> It wouldn't be much difficult from the build-system POV.
> The problem may be related to the way we include the lua headers:
> 
> #include "lua/include/lua.h"
> 
> I'll try to implement the check and then set a wxUSE_CUSTOM_LUA 
> preprocessor symbol if a usable lua 5.1 is found. The header inclusion 
> would then be modified:
> 
> #if wxUSE_CUSTOM_LUA
>     #include "lua.h"
> #else
>     #include "lua/include/lua.h"
> #endif
> 
> otherwise we could also simply add the "modules/lua/include" path to the 
> paths given to compiler so that we could just use:
> 
> #include "lua.h"
> 
> all the times.
I've done the change which now allows wxLua to be compiled against a 
system lua.

I've also fixed some other little problems with the build system.

Now everything should be ready (from the build system POV) for the 
release. If everyone could test the build system (in fact, I need to 
test it yet deeply under windows - i'll do that tomorrow), it would be 
great.

Francesco