wxlua-users Mailing List for wxLua (Page 4)

On Jan 17, 2008 1:27 PM, Rob Kendrick <rj...@rj...> wrote:
>
> On Thu, 2008-01-17 at 13:21 -0500, John Labenski wrote:
>
> > For the monolithic build:
> >
> > How do you envision it?
>
> I'd like to see just one DSO containing all the bindings that you can
> just do 'require "wx"' from inside a standard Lua interpreter.  Just one
> file you can put along side. (Excluding the WxWidgets DSOs themselves,
> obviously: although I suppose the bindings could statically link to them
> too, although that's not an option for me as Ubuntu doesn't come with
> static versions, but that's outside your control.)

So only wxLua's wx.so is monolithic. Ok, sounds fine.

 > Additionally, is there a way of detecting which features a specific
> build of the Wx bindings has from Lua?

Yes, you have access to all the binding information, classes, their
member functions and the parameters they take, everything. See
binding.wx.lua and wxlua.i in wxluaref.html.

Regards,
    John

On Jan 17, 2008 1:16 PM, Rob Kendrick <rj...@rj...> wrote:
>
> On Wed, 2008-01-16 at 08:54 +0000, Rob Kendrick wrote:
> > On Tue, 2008-01-15 at 13:50 -0500, John Labenski wrote:
> >
> > > However, if Ubuntu only has 2.8.4 then, if you would be so kind,
> > > please open wxaui_aui.cpp and compile, then rem out the lines or put
> > > dummy values, whatever it takes to get it to compile and write down
> > > the missing methods and post them here. I will add %wxchkver_2_8_7 on
> > > them so 2.8.4 will work.
> >
> > It seems to complain about the following in wxaui_aui.cpp:
> >
> > wxAuiTabCtrl_IsTabVisible
> > wxAuiTabCtrl_MakeTabVisble
> >
> > And this in wxaui_bind.cpp:
> >
> > wxAUI_NB_MIDDLE_CLICK_CLOSE
>
> Have you had a chance to investigate this, yet?  It's not a show-stopper
> for me, but it would reduce the complexity of my build system.

Thanks for reminding me, I had forgotten. I put %wxchkver_2_8_6 in
front of them in CVS.

Thanks,
     John

On Thu, 2008-01-17 at 13:21 -0500, John Labenski wrote:

> For the monolithic build:
> 
> How do you envision it?

I'd like to see just one DSO containing all the bindings that you can
just do 'require "wx"' from inside a standard Lua interpreter.  Just one
file you can put along side. (Excluding the WxWidgets DSOs themselves,
obviously: although I suppose the bindings could statically link to them
too, although that's not an option for me as Ubuntu doesn't come with
static versions, but that's outside your control.)

Additionally, is there a way of detecting which features a specific
build of the Wx bindings has from Lua?

B.

On Jan 17, 2008 12:53 PM, Ryan Pusztai <rpu...@gm...> wrote:
> On Jan 17, 2008 12:15 PM, Leslie Newell <les...@fm...> wrote:
>
> > Thanks John,
> >
> > It now works fine. By the way, do you have any intention of supporting a
> > monolithic wxLua build?
>
> Please! Please! Please! I am developing a Premake script to do this, but it
> would be much better in the build system you prefer.

Ok, one thing at a time, but I think we almost have everything else
working, but we'll only know that when people try it.

For the monolithic build:

How do you envision it? A single shared library with wxLua and all the
bindings? I assume this is so that wx.so/dll is just a single file.
Or?

Note: The wxLua libraries were separated since wxPython (for good or
bad) separates them, but goes even further by making you import each
library and even classes, "import wx; import wx.lib.docview" for
example.

Would wxLua like to have to have in addition to wx.so, wxlua.so,
wxlua_base.so, wxlua_core.so, wxlua_xxx so you can "require" only the
bits you really want.

Regards,
    John

On Wed, 2008-01-16 at 08:54 +0000, Rob Kendrick wrote:
> On Tue, 2008-01-15 at 13:50 -0500, John Labenski wrote:
> 
> > However, if Ubuntu only has 2.8.4 then, if you would be so kind,
> > please open wxaui_aui.cpp and compile, then rem out the lines or put
> > dummy values, whatever it takes to get it to compile and write down
> > the missing methods and post them here. I will add %wxchkver_2_8_7 on
> > them so 2.8.4 will work.
> 
> It seems to complain about the following in wxaui_aui.cpp:
> 
> wxAuiTabCtrl_IsTabVisible
> wxAuiTabCtrl_MakeTabVisble
> 
> And this in wxaui_bind.cpp:
> 
> wxAUI_NB_MIDDLE_CLICK_CLOSE

Have you had a chance to investigate this, yet?  It's not a show-stopper
for me, but it would reduce the complexity of my build system.

B.

On Jan 17, 2008 12:15 PM, Leslie Newell <les...@fm...> wrote:

> Thanks John,
>
> It now works fine. By the way, do you have any intention of supporting a
> monolithic wxLua build?


Please! Please! Please! I am developing a Premake script to do this, but it
would be much better in the build system you prefer.
-- 
Regards,
Ryan

Thanks John,

It now works fine. By the way, do you have any intention of supporting a 
monolithic wxLua build?

Les

John Labenski wrote:
> The wxLuaFreeze problem should be fixed now in CVS.
>
> Leslie, THREADING should be an option at the top of the makefile.vc
> set to multi, but for some reason bakefile is not writing it to the
> output.
>   

On Jan 17, 2008 8:41 AM, Leslie Newell <les...@fm...> wrote:
> Trying to compile with static runtime libs.
>
> BUILD = release
> UNICODE = 1
> SHARED = 0
> WX_SHARED = 0
> WX_MONOLITHIC = 0
> RUNTIME_LIBS = static
>
> To get it to compile I need to do the following
> Add this line to wxLua/build/makefile.vc
> THREADING = multi
> in wxLua\modules\build\msw\makefile.vc
> LUA_LIB_CFLAGS = /MD$(VAR_199) /DWIN32 $(VAR) $(VAR_196) $(VAR_198) \
> changed to:
> LUA_LIB_CFLAGS = /M$(__RUNTIME_LIBS_27)$(VAR_199) /DWIN32 $(VAR)
> $(VAR_196) $(VAR_198) \
>
> As before I need to disable wxLuaFreeze.
> Apart from that it compiled but I haven't tested it all yet...

The wxLuaFreeze problem should be fixed now in CVS.

Leslie, THREADING should be an option at the top of the makefile.vc
set to multi, but for some reason bakefile is not writing it to the
output.

Francesco, in build/bakefiles/options.bkl there is <option
name="THREADING">, but it doesn't appear in the output. Does the new
version of bakefile have a problem stripping out too many variables?
(like the wxLUA_USEBINDING_XXX problem in the other message)

Regards,
    John

Trying to compile with static runtime libs.

BUILD = release
UNICODE = 1
SHARED = 0
WX_SHARED = 0
WX_MONOLITHIC = 0
RUNTIME_LIBS = static

To get it to compile I need to do the following
Add this line to wxLua/build/makefile.vc
THREADING = multi
in wxLua\modules\build\msw\makefile.vc
LUA_LIB_CFLAGS = /MD$(VAR_199) /DWIN32 $(VAR) $(VAR_196) $(VAR_198) \
changed to:
LUA_LIB_CFLAGS = /M$(__RUNTIME_LIBS_27)$(VAR_199) /DWIN32 $(VAR) 
$(VAR_196) $(VAR_198) \

As before I need to disable wxLuaFreeze.
Apart from that it compiled but I haven't tested it all yet...

Thanks,
Les

Hi John,

The gl problem is fixed but I am afraid the wxLuaFreeze issue is still 
there:

        link /NOLOGO /OUT:..\..\..\bin\vc_dll\wxluafreeze.exe  
/LIBPATH:c:\wxWid
gets-2.8.6\lib\vc_dll /DEBUG /pdb:"..\..\..\bin\vc_dll\wxluafreeze.pdb"  
/LIBPAT
H:..\..\..\lib\vc_dll /LIBPATH:..\..\..\modules\lua\lib 
/SUBSYSTEM:WINDOWS @C:\D
OCUME~1\LESNEW~1\LOCALS~1\Temp\nm32.tmp
app_wxluafreeze_wxluafreeze.obj : error LNK2019: unresolved external 
symbol "__d
eclspec(dllimport) bool __cdecl wxLuaBinding_wxgl_init(void)" 
(__imp_?wxLuaBindi
ng_wxgl_init@@YA_NXZ) referenced in function "public: virtual bool 
__thiscall wx
LuaFreezeApp::OnInit(void)" (?OnInit@wxLuaFreezeApp@@UAE_NXZ)
..\..\..\bin\vc_dll\wxluafreeze.exe : fatal error LNK1120: 1 unresolved 
external
s

Just to refresh your memory:
BUILD = debug
UNICODE = 1
SHARED = 1
WX_SHARED = 1

As it happens I don't need wxLuaFreeze so this isn't a major problem for me.

Now to test the static release build ;-)

Thanks,
Les

On Jan 16, 2008 2:20 PM, John Labenski <jla...@gm...> wrote:
> On Jan 16, 2008 2:06 PM, Francesco Montorsi <f18...@ya...> wrote:
>
> > In fact, the USE_WXBIND* options do not appear in the win32's apps
> > makefiles because they aren't used anywhere by apps.bkl and thus
> > Bakefile prunes them as unused.
>
> That explains it.

Humm, I think bakefile is pruning the code for the var since
"-DDEF_wxLUA_USEBINDING_WXXXX" appears as a compiler directive, but I
cannot make it generate the variable DEF_wxLUA_USEBINDING_WX itself.

http://wxlua.cvs.sourceforge.net/wxlua/wxLua/apps/build/msw/makefile.vc?revision=1.77&view=markup

I've instead gone for the much simpler
<define>wxLUA_USEBINDING_WXADV=$(USE_WXBINDADV)</define>

I've also added a new
<template id="wxlua_with_bindings" tempate="wxlua">
that
<template id="wxluaapp" template="wxlua_with_bindings">
is derived from since we don't need the above conditions for the modules.

http://wxlua.cvs.sourceforge.net/wxlua/wxLua/build/bakefiles/wxluabase.bkl?r1=1.47&r2=1.48

Regards,
    John




> > >   <define-global-tag name="define-usewxbind-def">
> > >      <set var="DEF_wxLUA_USEBINDING_WX$(value.upper())">
> > >           <if cond="USE_WXBIND$(value.upper())=='0">
> > >               wxLUA_USEBINDING_WX$(value.upper())=0
> > >            </if>
>
> > >             How to make an <else>? and this is just a dummy
> > >             since <define> will make this "-DA=A", but how to make it
> > >             nicer?
> > >             <if cond="USE_WXBIND$(value.upper())=='1">
> > >                 A=A
> > >             </if>
> > this piece is not needed however. Just leave the
> > DEF_wxLUA_USEBINDING_WX* vars empty if =='1':
> >
> >    <define-global-tag name="define-usewxbind-def">
> >          <set var="DEF_wxLUA_USEBINDING_WX$(value.upper())">
> >              <if cond="USE_WXBIND$(value.upper())=='0">
> >                  wxLUA_USEBINDING_WX$(value.upper())=0
> >              </if>
> >          </set>
> >      </define-global-tag>
> >
> > it *should* work (untested)...
> >
> > > Then in "<template id="wxlua"...>"  add these since we can't do conditions here.
> > >     <define>DEF_wxLUA_USEBINDING_WXADV</define>
> > >     <define>DEF_wxLUA_USEBINDING_WXAUI</define>
> > >
> > > Does this make sense?
> > a lot ;)
>
> But if DEF_wxLUA_USEBINDING_WXADV is empty won't we get stray "-D"
> compiler directives? That's why I added the "A=A" hack because the
> value of DEF_wxLUA_USEBINDING_WXADV is determined in the makefile and
> so bakefile cannot trim out empty <define>s leaving
> "-D$DEF_wxLUA_USEBINDING_WXADV" which == "-D".
>
> In any case, I will try the above and see what happens.
>
> Thanks,
>     John
>

On Jan 16, 2008 1:50 PM, Francesco Montorsi <f18...@ya...> wrote:
> John Labenski ha scritto:
> > On Jan 16, 2008 7:07 AM, Leslie Newell <les...@fm...> wrote:
> >> The GL lib is separate even in monolithic builds. The lines should read:
> > Hopefully they're both fixed in the current CVS.
> Thanks. I'll make sure the fix is committed also upstream in wx.
>

Sorry I had meant to alert you to that change, but forgot.

================

Is the code below equivalent? Is generates a lot less code in the msw
makefiles. (see wx_win32.bkl)


This
        <if cond="WX_MONOLITHIC=='0' and WX_UNICODE=='0' and
WX_DEBUG=='0'">wxbase$(WX_VERSION)</if>
        <if cond="WX_MONOLITHIC=='0' and WX_UNICODE=='0' and
WX_DEBUG=='1'">wxbase$(WX_VERSION)d</if>
        <if cond="WX_MONOLITHIC=='0' and WX_UNICODE=='1' and
WX_DEBUG=='0'">wxbase$(WX_VERSION)u</if>
        <if cond="WX_MONOLITHIC=='0' and WX_UNICODE=='1' and
WX_DEBUG=='1'">wxbase$(WX_VERSION)ud</if>

is same as
        <if cond="WX_MONOLITHIC=='0'">wxbase$(WX_VERSION)$(WXLIBPOSTFIX)</if>

================
And this
        <if cond="WX_MONOLITHIC=='1' and WX_UNICODE=='0' and
WX_DEBUG=='0'">wx$(WX_PORT)$(WX_VERSION)</if>
        <if cond="WX_MONOLITHIC=='1' and WX_UNICODE=='0' and
WX_DEBUG=='1'">wx$(WX_PORT)$(WX_VERSION)d</if>
        <if cond="WX_MONOLITHIC=='1' and WX_UNICODE=='1' and
WX_DEBUG=='0'">wx$(WX_PORT)$(WX_VERSION)u</if>
        <if cond="WX_MONOLITHIC=='1' and WX_UNICODE=='1' and
WX_DEBUG=='1'">wx$(WX_PORT)$(WX_VERSION)ud</if>

is same as
        <if cond="WX_MONOLITHIC=='0'">wx$(WX_VERSION)$(WXLIBPOSTFIX)</if>

================
This
    <define-global-tag name="define-wxbase-lib-name">
        <set var="WXLIB_$(value.upper())_NAME">
            <if cond="WX_MONOLITHIC=='0' and WX_UNICODE=='0' and WX_DEBUG=='0'">
                wxbase$(WX_VERSION)_$(value)
            </if>
            <if cond="WX_MONOLITHIC=='0' and WX_UNICODE=='0' and WX_DEBUG=='1'">
                wxbase$(WX_VERSION)d_$(value)
            </if>
            <if cond="WX_MONOLITHIC=='0' and WX_UNICODE=='1' and WX_DEBUG=='0'">
                wxbase$(WX_VERSION)u_$(value)
            </if>
            <if cond="WX_MONOLITHIC=='0' and WX_UNICODE=='1' and WX_DEBUG=='1'">
                wxbase$(WX_VERSION)ud_$(value)
            </if>
        </set>
    </define-global-tag>

is same as
    <define-global-tag name="define-wxbase-lib-name">
        <set var="WXLIB_$(value.upper())_NAME">
            <if cond="WX_MONOLITHIC=='0'">
                wxbase$(WX_VERSION)$(WXLIBPOSTFIX)_$(value)
            </if>
        </set>
    </define-global-tag>

================
And finally
    <define-global-tag name="define-wxlib-name">
        <set var="WXLIB_$(value.upper())_NAME">
            <if cond="WX_MONOLITHIC=='0' and WX_UNICODE=='0' and WX_DEBUG=='0'">
                wx$(WX_PORT)$(WX_VERSION)_$(value)
            </if>
            <if cond="WX_MONOLITHIC=='0' and WX_UNICODE=='0' and WX_DEBUG=='1'">
                wx$(WX_PORT)$(WX_VERSION)d_$(value)
            </if>
            <if cond="WX_MONOLITHIC=='0' and WX_UNICODE=='1' and WX_DEBUG=='0'">
                wx$(WX_PORT)$(WX_VERSION)u_$(value)
            </if>
            <if cond="WX_MONOLITHIC=='0' and WX_UNICODE=='1' and WX_DEBUG=='1'">
                wx$(WX_PORT)$(WX_VERSION)ud_$(value)
            </if>
        </set>
    </define-global-tag>

is same as

    <define-global-tag name="define-wxlib-name">
        <set var="WXLIB_$(value.upper())_NAME">
            <if cond="WX_MONOLITHIC=='0'">
                wx$(WX_PORT)$(WX_VERSION)$(WXLIBPOSTFIX)_$(value)
            </if>
        </set>
    </define-global-tag>

Regards,
    John

On Jan 16, 2008 2:06 PM, Francesco Montorsi <f18...@ya...> wrote:

> In fact, the USE_WXBIND* options do not appear in the win32's apps
> makefiles because they aren't used anywhere by apps.bkl and thus
> Bakefile prunes them as unused.

That explains it.

> >   <define-global-tag name="define-usewxbind-def">
> >      <set var="DEF_wxLUA_USEBINDING_WX$(value.upper())">
> >           <if cond="USE_WXBIND$(value.upper())=='0">
> >               wxLUA_USEBINDING_WX$(value.upper())=0
> >            </if>

> >             How to make an <else>? and this is just a dummy
> >             since <define> will make this "-DA=A", but how to make it
> >             nicer?
> >             <if cond="USE_WXBIND$(value.upper())=='1">
> >                 A=A
> >             </if>
> this piece is not needed however. Just leave the
> DEF_wxLUA_USEBINDING_WX* vars empty if =='1':
>
>    <define-global-tag name="define-usewxbind-def">
>          <set var="DEF_wxLUA_USEBINDING_WX$(value.upper())">
>              <if cond="USE_WXBIND$(value.upper())=='0">
>                  wxLUA_USEBINDING_WX$(value.upper())=0
>              </if>
>          </set>
>      </define-global-tag>
>
> it *should* work (untested)...
>
> > Then in "<template id="wxlua"...>"  add these since we can't do conditions here.
> >     <define>DEF_wxLUA_USEBINDING_WXADV</define>
> >     <define>DEF_wxLUA_USEBINDING_WXAUI</define>
> >
> > Does this make sense?
> a lot ;)

But if DEF_wxLUA_USEBINDING_WXADV is empty won't we get stray "-D"
compiler directives? That's why I added the "A=A" hack because the
value of DEF_wxLUA_USEBINDING_WXADV is determined in the makefile and
so bakefile cannot trim out empty <define>s leaving
"-D$DEF_wxLUA_USEBINDING_WXADV" which == "-D".

In any case, I will try the above and see what happens.

Thanks,
    John

Hi,

John Labenski ha scritto:
> Hi Francesco,
>    I think we need to make the apps makefiles use the USE_WXBINDXXX
> conditions defined in modules/bakefiles/options.bkl so that if you run
> the makefile in wxLua/build/msw your preferences pass through to the
> apps makefile.
right...


> 1) It looks like it might be best to put the contents of
> modules/bakefile/options.bkl into build/bakefile/options.bkl so
> everything is defined for all the makefiles.
hmmm, currently apps/build/bakefiles/apps.bkl already includes the 
modules's list of options, so putting all options in a single file 
wouldn't solve the problem.
In fact, the USE_WXBIND* options do not appear in the win32's apps 
makefiles because they aren't used anywhere by apps.bkl and thus 
Bakefile prunes them as unused.

So this movement of options is not needed IMO and would also make the 
final option file less maintainable.


> 2) We need to then tie the bakefile USE_WXBINDXXX conditions to the
> compiler directive -DwxLUA_USEBINDING_WXXXX=0 which controls the
> initialization of the bindings for the apps. By default
> wxLUA_USEBINDING_WXXXX=1 so we don't need to turn it on, but we do
> need to turn it off. See modules/wxbind/include/wxbinddefs.h
> 
> #ifndef wxLUA_USEBINDING_WXADV
>     #define wxLUA_USEBINDING_WXADV                      1
> #endif
> 
> How can we most easily do this?
> 
> Add this?
> 
>     <define-global-tag name="define-usewxbind-def">
>         <set var="DEF_wxLUA_USEBINDING_WX$(value.upper())">
>             <if cond="USE_WXBIND$(value.upper())=='0">
>                 wxLUA_USEBINDING_WX$(value.upper())=0
>             </if>
this is a good idea!


> 
>             How to make an <else>? and this is just a dummy
>             since <define> will make this "-DA=A", but how to make it
>             nicer?
>             <if cond="USE_WXBIND$(value.upper())=='1">
>                 A=A
>             </if>
this piece is not needed however. Just leave the 
DEF_wxLUA_USEBINDING_WX* vars empty if =='1':

   <define-global-tag name="define-usewxbind-def">
         <set var="DEF_wxLUA_USEBINDING_WX$(value.upper())">
             <if cond="USE_WXBIND$(value.upper())=='0">
                 wxLUA_USEBINDING_WX$(value.upper())=0
             </if>
         </set>
     </define-global-tag>

it *should* work (untested)...

> Then in "<template id="wxlua"...>"  add these since we can't do conditions here.
>     <define>DEF_wxLUA_USEBINDING_WXADV</define>
>     <define>DEF_wxLUA_USEBINDING_WXAUI</define>
> 
> Does this make sense?
a lot ;)

Francesco

John Labenski ha scritto:
> On Jan 16, 2008 7:07 AM, Leslie Newell <les...@fm...> wrote:
>> The GL lib is separate even in monolithic builds. The lines should read:
> Hopefully they're both fixed in the current CVS.
Thanks. I'll make sure the fix is committed also upstream in wx.

Francesco

Hi Francesco,
   I think we need to make the apps makefiles use the USE_WXBINDXXX
conditions defined in modules/bakefiles/options.bkl so that if you run
the makefile in wxLua/build/msw your preferences pass through to the
apps makefile.

1) It looks like it might be best to put the contents of
modules/bakefile/options.bkl into build/bakefile/options.bkl so
everything is defined for all the makefiles.

2) We need to then tie the bakefile USE_WXBINDXXX conditions to the
compiler directive -DwxLUA_USEBINDING_WXXXX=0 which controls the
initialization of the bindings for the apps. By default
wxLUA_USEBINDING_WXXXX=1 so we don't need to turn it on, but we do
need to turn it off. See modules/wxbind/include/wxbinddefs.h

#ifndef wxLUA_USEBINDING_WXADV
    #define wxLUA_USEBINDING_WXADV                      1
#endif

How can we most easily do this?

Add this?

    <define-global-tag name="define-usewxbind-def">
        <set var="DEF_wxLUA_USEBINDING_WX$(value.upper())">
            <if cond="USE_WXBIND$(value.upper())=='0">
                wxLUA_USEBINDING_WX$(value.upper())=0
            </if>

            How to make an <else>? and this is just a dummy
            since <define> will make this "-DA=A", but how to make it
            nicer?
            <if cond="USE_WXBIND$(value.upper())=='1">
                A=A
            </if>
        </set>
    </define-global-tag>

<define-usewxbind-def>aui</define-usewxbind-def>
<define-usewxbind-def>adv</define-usewxbind-def>
...

Then in "<template id="wxlua"...>"  add these since we can't do conditions here.
    <define>DEF_wxLUA_USEBINDING_WXADV</define>
    <define>DEF_wxLUA_USEBINDING_WXAUI</define>

Does this make sense?
    John

On Jan 16, 2008 7:07 AM, Leslie Newell <les...@fm...> wrote:
> Hi John,
>
> Found it. In modules/build/msw/makefile.vc
>
> !if "$(BUILD)" == "debug" && "$(UNICODE)" == "0" && "$(WX_MONOLITHIC)"
> == "0"
> __WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)d_gl.lib
> !endif
...
>
> The GL lib is separate even in monolithic builds. The lines should read:
>
> !if "$(BUILD)" == "debug" && "$(UNICODE)" == "0"
> __WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)d_gl.lib
> !endif
...
>
> Just one of those little wx quirks to catch out the unwary ;-)
>
> Next problem:
>
>         link /NOLOGO /OUT:..\..\..\bin\vc_dll\wxluafreeze.exe
> /LIBPATH:c:\wxWid
> gets-2.8.6\lib\vc_dll /DEBUG /pdb:"..\..\..\bin\vc_dll\wxluafreeze.pdb"
> /LIBPAT
> H:..\..\..\lib\vc_dll /LIBPATH:..\..\..\modules\lua\lib
> /SUBSYSTEM:WINDOWS @C:\D
> OCUME~1\LESNEW~1\LOCALS~1\Temp\nm5F.tmp
> app_wxluafreeze_wxluafreeze.obj : error LNK2019: unresolved external
> symbol "__d
> eclspec(dllimport) bool __cdecl wxLuaBinding_wxgl_init(void)"
> (__imp_?wxLuaBindi
> ng_wxgl_init@@YA_NXZ) referenced in function "public: virtual bool
> __thiscall wx
> LuaFreezeApp::OnInit(void)" (?OnInit@wxLuaFreezeApp@@UAE_NXZ)
> ..\..\..\bin\vc_dll\wxluafreeze.exe : fatal error LNK1120: 1 unresolved
> external

Hopefully they're both fixed in the current CVS.

I will post separately about a a problem with the bigger picture however.

Regards,
    John

Hi John,

Found it. In modules/build/msw/makefile.vc

!if "$(BUILD)" == "debug" && "$(UNICODE)" == "0" && "$(WX_MONOLITHIC)" 
== "0"
__WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)d_gl.lib
!endif
!if "$(BUILD)" == "debug" && "$(UNICODE)" == "1" && "$(WX_MONOLITHIC)" 
== "0"
__WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)ud_gl.lib
!endif
!if "$(BUILD)" == "release" && "$(UNICODE)" == "0" && "$(WX_MONOLITHIC)" 
== "0"
__WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)_gl.lib
!endif
!if "$(BUILD)" == "release" && "$(UNICODE)" == "1" && "$(WX_MONOLITHIC)" 
== "0"
__WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)u_gl.lib
!endif

The GL lib is separate even in monolithic builds. The lines should read:

!if "$(BUILD)" == "debug" && "$(UNICODE)" == "0"
__WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)d_gl.lib
!endif
!if "$(BUILD)" == "debug" && "$(UNICODE)" == "1"
__WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)ud_gl.lib
!endif
!if "$(BUILD)" == "release" && "$(UNICODE)" == "0"
__WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)_gl.lib
!endif
!if "$(BUILD)" == "release" && "$(UNICODE)" == "1"
__WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)u_gl.lib
!endif

Just one of those little wx quirks to catch out the unwary ;-)

Next problem:

        link /NOLOGO /OUT:..\..\..\bin\vc_dll\wxluafreeze.exe  
/LIBPATH:c:\wxWid
gets-2.8.6\lib\vc_dll /DEBUG /pdb:"..\..\..\bin\vc_dll\wxluafreeze.pdb"  
/LIBPAT
H:..\..\..\lib\vc_dll /LIBPATH:..\..\..\modules\lua\lib 
/SUBSYSTEM:WINDOWS @C:\D
OCUME~1\LESNEW~1\LOCALS~1\Temp\nm5F.tmp
app_wxluafreeze_wxluafreeze.obj : error LNK2019: unresolved external 
symbol "__d
eclspec(dllimport) bool __cdecl wxLuaBinding_wxgl_init(void)" 
(__imp_?wxLuaBindi
ng_wxgl_init@@YA_NXZ) referenced in function "public: virtual bool 
__thiscall wx
LuaFreezeApp::OnInit(void)" (?OnInit@wxLuaFreezeApp@@UAE_NXZ)
..\..\..\bin\vc_dll\wxluafreeze.exe : fatal error LNK1120: 1 unresolved 
external

Thanks,
Les


John Labenski wrote:
> On Jan 15, 2008 12:50 PM, Leslie Newell <les...@fm...> wrote:
>   
>> Thank John. That fixed it. I now get a bunch of unresolved externals,
>> all related to OpenGl. For example:
>>
>> wxbindgl_dll_wxgl_gl.obj : error LNK2001: unresolved external symbol
>> "public: vi
>> rtual class wxClassInfo * __thiscall
>> wxGLContext::GetClassInfo(void)const " (?Ge
>> tClassInfo@wxGLContext@@UBEPAVwxClassInfo@@XZ)
>>
>> I have OpenGl enabled in wx.
>>     
>
> Please show me the compile line just before the error message.
>
> I see in modules/build/msw/makefile.vc that if the wxbindgl module is
> built that the wxWidgets gl library should be linked to it. Search for
> __WXLIB_GL_NAME_p in that file, what is going wrong? Do you have
> mismatched release/debug and/or ansi/unicode values between the
> wxWidgets libs and the wxLua you're trying to build?
>
> Thanks,
>     John
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>   

John Labenski wrote:

> Anders, what do you think needs to change to make compiling on OSX run 
> smoothly?

Not much, maybe just need to add a little to the fixup scripts...

> My preferred method of compiling both wxWidgets and wxLua is to create
> a dir "wxLua/config_osxud" (unicode, debug) and then running
> $../configure --prefix=/Users/john/.../wxLua/config_osxud
> $make
> so everything is nicely within the config_osxud dir and I can quickly
> delete that to start over.
> I create a link ~/bin/wx-config -> to my preferred wx-config, where
> ~/bin in first in my bash path.

Right, I have pretty much the same but in my /usr/local instead.

My wxWidgets installation is a 10.4+ Universal Binary configuration,
so the configure is a little (=much) more convoluted but similar.

I also made sure to install the OpenGL and the STC components.
Normally I build the regular wx libs as "monolithic", though.

> Ok, so this is not "standard" as opposed to installing to a "system"
> dir like /usr/local , but I do not want to have to dig out and delete
> the installed files when drastic changes are necessary.

Okies. Guess you could use something like /opt/wxWidgets too ?

> So... anyway
>
> 1) I see that after running the above that wxLua.app (all the apps)
> are installed into apps/. Should we change the target, for example,
> wxLua.app/Contents/PkgInfo in the generated apps/Makefile to create
> wxLua.app in bin/ ?

I'm fine with having the bundles in "apps", and "bin" stay sane.

If anything, they should go in "Applications" or something... ?
And it should probably use Frameworks, instead of regular dylibs.
Porting to Xcode projects could also be done, even more Kool-Aid.
But that's all a lot of hassle, so might as well keep it in "apps".

Makes wxMac more similar to the other ports (wxGTK and wxMSW),
even if the wxWidgets guys have decided* that you need to either
wrap the binaries in bundles or to add resource forks to them
if you want them to be able to receive any events after startup.

* see http://lists.wxwidgets.org/archive/wx-dev/msg83276.html

> 2) What is the deleting and moving part of
> distrib/macbundle/copydylibs.command supposed to do?
> I think it assumes that you've run $./configure in the root dir of 
> wxLua.
>
> $cd distrib/macbundle
> $copy ../lib/*.dylib .     <--- ? should be ../../lib/*.dylib ?
> $rm libwxlua_macud_wxlua_2.8.0.dylib  <- the symbolic link
>    What about the other symbolic link libwxlua_macud_wxlua_2.8.dylib?
> $mv real lib to *0.dylib
> I get what the install_name_tool parts are doing.

It's supposed to move all required wx libraries into the
apps folder so that all the app bundles are "clickable".

Should probably have one copy of wxWidgets and wxLua
for each application, but I put them all next to the
apps to cut down on the insane amount of bloat otherwise.
This was for the "stand-alone" installation, in the DMG.

For MacPorts, nothing is relinked and everything links
off to the ${prefix} (normally it is set to /opt/local)
There it can have a dependency on the "wxWidgets" port
(or "wxgtk" for X11), so doesn't have to bundle anything.

> If I understand correctly we want the real dylibs renamed to
> reallibname.0.dylib, which was originally a link. Finally where does
> all these libs go? When the script ends it looks like they'll still be
> in distrib/macbundle.

Well, one could copy the "real" dylibs and the symlinks too,
think I was just lazy - and wanted less clutter for the user.

Double-check the wxLua DMG to make sure, but I think is was meant
to be run from within the "apps" folder ? Other was just a copy.

http://downloads.sourceforge.net/wxlua/wxlua-2.8.4.1-tiger.dmg

> 3) After compiling with the above method, wxLua.app segfaults because
> it's confused about what dynamic libs to use. When I run
> $otool -L wxLua.app/Contents/MacOS/wxLua
> I see that it's linked to all my wx-config libs except for
> /usr/lib/libwx_macud_stc_2.8.0.dylib and same for the gl lib. Ugh. I
> see that the Osx replacement for LD_LIBRARY_PATH is dyld, but is there
> a simpler way? Do you not have this problem?

I'm not using the old Apple wxWidgets libraries, and I'm
using the "release" variant instead of the "debug" variant.

I haven't updated the above script for wxLua 2.8.7.0 yet,
but it was used for wxLua 2.8.4.1 - as far as I remember...

--anders

On Tue, 2008-01-15 at 13:50 -0500, John Labenski wrote:

> However, if Ubuntu only has 2.8.4 then, if you would be so kind,
> please open wxaui_aui.cpp and compile, then rem out the lines or put
> dummy values, whatever it takes to get it to compile and write down
> the missing methods and post them here. I will add %wxchkver_2_8_7 on
> them so 2.8.4 will work.

It seems to complain about the following in wxaui_aui.cpp:

wxAuiTabCtrl_IsTabVisible
wxAuiTabCtrl_MakeTabVisble

And this in wxaui_bind.cpp:

wxAUI_NB_MIDDLE_CLICK_CLOSE

B.

ps. I would like any code fixes you've made too. For example I've
fixed the id !=3D 0 error that wxLuaCan has for one of it's menu ids in
CVS.

Thanks,
    John


On Jan 16, 2008 12:48 AM, John Labenski <jla...@gm...> wrote:
> On Jan 14, 2008 5:39 PM, Anders F Bj=F6rklund <af...@al...> wrote:
> > Francesco Montorsi wrote:
> >
> > > But I'm unsure this is really necessary and instead I think it's nice
> > > to
> > > have the rpath stuff also under Mac (so that you can run binaries whe=
n
> > > you compile wxLua before installing system-wide)...
> >
> > There is a "rpath" of sorts in older Mac OS X too, and it can be tweake=
d
> > by using install_name_tool on the binaries after building for instance*=
.
> > If you look at the wxLua "distrib/macbundle/copydylibs.command" script,
> > it changes the location of the libs when installing the .dylib (=3D.so)
> >
> > It changes the default linker path of /usr/local/lib/libfoo.dylib
> > into a local path like @executable_path/../../../libfoo.dylib
> > (where the "@executable_path" string is automagically replaced
> > with the location of the current program, on application start)
> >
> > The extra two .. levels is for "wxFoo.app/Contents/MacOS/wxFoo",
> > i.e. to break out of the directory structure of the app bundle
>
> Anders, what do you think needs to change to make compiling on OSX run sm=
oothly?
>
> My preferred method of compiling both wxWidgets and wxLua is to create
> a dir "wxLua/config_osxud" (unicode, debug) and then running
> $../configure --prefix=3D/Users/john/.../wxLua/config_osxud
> $make
> so everything is nicely within the config_osxud dir and I can quickly
> delete that to start over.
> I create a link ~/bin/wx-config -> to my preferred wx-config, where
> ~/bin in first in my bash path.
>
> Ok, so this is not "standard" as opposed to installing to a "system"
> dir like /usr/local , but I do not want to have to dig out and delete
> the installed files when drastic changes are necessary.
>
> So... anyway
>
> 1) I see that after running the above that wxLua.app (all the apps)
> are installed into apps/. Should we change the target, for example,
> wxLua.app/Contents/PkgInfo in the generated apps/Makefile to create
> wxLua.app in bin/ ?
>
> 2) What is the deleting and moving part of
> distrib/macbundle/copydylibs.command supposed to do?
> I think it assumes that you've run $./configure in the root dir of wxLua.
>
> $cd distrib/macbundle
> $copy ../lib/*.dylib .     <--- ? should be ../../lib/*.dylib ?
> $rm libwxlua_macud_wxlua_2.8.0.dylib  <- the symbolic link
>    What about the other symbolic link libwxlua_macud_wxlua_2.8.dylib?
> $mv real lib to *0.dylib
> I get what the install_name_tool parts are doing.
>
> If I understand correctly we want the real dylibs renamed to
> reallibname.0.dylib, which was originally a link. Finally where does
> all these libs go? When the script ends it looks like they'll still be
> in distrib/macbundle.
>
> 3) After compiling with the above method, wxLua.app segfaults because
> it's confused about what dynamic libs to use. When I run
> $otool -L wxLua.app/Contents/MacOS/wxLua
> I see that it's linked to all my wx-config libs except for
> /usr/lib/libwx_macud_stc_2.8.0.dylib and same for the gl lib. Ugh. I
> see that the Osx replacement for LD_LIBRARY_PATH is dyld, but is there
> a simpler way? Do you not have this problem?
>
> Thanks,
>     John
>

On Jan 14, 2008 5:39 PM, Anders F Bj=F6rklund <af...@al...> wrote:
> Francesco Montorsi wrote:
>
> > But I'm unsure this is really necessary and instead I think it's nice
> > to
> > have the rpath stuff also under Mac (so that you can run binaries when
> > you compile wxLua before installing system-wide)...
>
> There is a "rpath" of sorts in older Mac OS X too, and it can be tweaked
> by using install_name_tool on the binaries after building for instance*.
> If you look at the wxLua "distrib/macbundle/copydylibs.command" script,
> it changes the location of the libs when installing the .dylib (=3D.so)
>
> It changes the default linker path of /usr/local/lib/libfoo.dylib
> into a local path like @executable_path/../../../libfoo.dylib
> (where the "@executable_path" string is automagically replaced
> with the location of the current program, on application start)
>
> The extra two .. levels is for "wxFoo.app/Contents/MacOS/wxFoo",
> i.e. to break out of the directory structure of the app bundle

Anders, what do you think needs to change to make compiling on OSX run smoo=
thly?

My preferred method of compiling both wxWidgets and wxLua is to create
a dir "wxLua/config_osxud" (unicode, debug) and then running
$../configure --prefix=3D/Users/john/.../wxLua/config_osxud
$make
so everything is nicely within the config_osxud dir and I can quickly
delete that to start over.
I create a link ~/bin/wx-config -> to my preferred wx-config, where
~/bin in first in my bash path.

Ok, so this is not "standard" as opposed to installing to a "system"
dir like /usr/local , but I do not want to have to dig out and delete
the installed files when drastic changes are necessary.

So... anyway

1) I see that after running the above that wxLua.app (all the apps)
are installed into apps/. Should we change the target, for example,
wxLua.app/Contents/PkgInfo in the generated apps/Makefile to create
wxLua.app in bin/ ?

2) What is the deleting and moving part of
distrib/macbundle/copydylibs.command supposed to do?
I think it assumes that you've run $./configure in the root dir of wxLua.

$cd distrib/macbundle
$copy ../lib/*.dylib .     <--- ? should be ../../lib/*.dylib ?
$rm libwxlua_macud_wxlua_2.8.0.dylib  <- the symbolic link
   What about the other symbolic link libwxlua_macud_wxlua_2.8.dylib?
$mv real lib to *0.dylib
I get what the install_name_tool parts are doing.

If I understand correctly we want the real dylibs renamed to
reallibname.0.dylib, which was originally a link. Finally where does
all these libs go? When the script ends it looks like they'll still be
in distrib/macbundle.

3) After compiling with the above method, wxLua.app segfaults because
it's confused about what dynamic libs to use. When I run
$otool -L wxLua.app/Contents/MacOS/wxLua
I see that it's linked to all my wx-config libs except for
/usr/lib/libwx_macud_stc_2.8.0.dylib and same for the gl lib. Ugh. I
see that the Osx replacement for LD_LIBRARY_PATH is dyld, but is there
a simpler way? Do you not have this problem?

Thanks,
    John

On Jan 15, 2008 6:00 PM, Francesco Montorsi <f18...@ya...> wrote:
>
> > I'm not sure we want to force "$lua_prefix/include/lua5.1" because
> > we're going to find someone with some system who has it elsewhere and
> > then we'll have more problems.
> typically this problem in the configure script I've found in other
> packages are "resolved" putting a list of paths to check; e.g.:
>
>   for d in /usr/local/include/lua5.1 /usr/local/include ... ; do
>      # check if $d is a valid folder
>   done

I don't think we have to ensure that it works with just "$configure"
out of the box, but we do have to make it possible for people to
override the paths to be able to make it work. Otherwise they're
locked into some preconceived notion about how things should be, but
aren't for reasons out of their control.

Slackware does this:
http://sotirov-bg.net/slackpack/pack.cgi?id=223&dump=true

usr/include/lua/5.1/lua.h
usr/lib/lua/5.1/liblua.a

We've got a couple options I think:
1) Add --with-lua-libpath which fills $LUA_LIB_DIR
2) Make them do export LDFLAGS="-L/path/to/lua/lib"

> > I would have kept this code, the includes can be anywhere, but the
> > system Lua libs should be in usr/lib or usr/local/lib or somewhere in
> > the  standard lib search path
> Typically, if the includes are in e.g. xxx/include/lua5.1, then the
> relative library should be in xxx/lib, i.e. if headers are installed in
> a certain prefix, then the library should be in that same prefix.

See above.

> > so I set our Lua lib path to the local
> > one which is a harmless duplication.
> this is in particular what I do not understand: why creating a
> LUA_LIB_DIR and then set it to our local lib folder, which is not going
> to ever contain the lua library if USE_SYSTEM_LUA=1?

Because $LUA_LIB_DIR is used by all the compilers to specify where to
put the built libs and their linking path; it replaces "$LUA_DIR/lib".

In the case of USE_SYSTEM_LUA=1 we don't need it, but I imagine that
it would be very hard/awkward/messy to get bakefile to not generate it
for this single special case so we merely set it to the existing wxLua
lib path. Since it will only be used as -L$(LUA_LIB_DIR) it does
nothing new because we've already got that that lib path specified.

> If we allow for an option called --with-lua-prefix then we must respect
> the prefix given by the user using it as base for both the include and
> the lib search folders.

People do crazy things... Heck, the tgz of Lua doesn't even have an
include/ dir anymore, just src/.

> Anyway if the current code works, there's no need to further loose time
> on it ;)

I agree whole-heartedly that this build upgrade is exhausting. :)

But, I think we definitely need to make it possible to completely
specify the include path to Lua so it won't come up as a problem
again. What do you think about the two options above for how to allow
people to specify the Lua lib path?

Regards,
    John

Hi,

John Labenski ha scritto:
>>> Fixed now, hopefully, please try again.
>> Sorry, but I don't understand this last change to configure.ac...
>>
>> I've modified the test and tested it under Ubuntu 7.10 with system's
>> lua5.1 installed and it seems to work...
>>
> 
> The Ubuntu package liblua5.1-0-dev puts the includes in
> "/usr/include/lua5.1". My last commit for the bakefiles and
> configure.ac was to remove the "/include" from $(LUA_DIR)/include so
> you could exactly specify where the includes are.
decoupling the include folder from the lib folder is ok :)

> I'm not sure we want to force "$lua_prefix/include/lua5.1" because
> we're going to find someone with some system who has it elsewhere and
> then we'll have more problems.
typically this problem in the configure script I've found in other 
packages are "resolved" putting a list of paths to check; e.g.:

  for d in /usr/local/include/lua5.1 /usr/local/include ... ; do
     # check if $d is a valid folder
  done

> I would have kept this code, the includes can be anywhere, but the
> system Lua libs should be in usr/lib or usr/local/lib or somewhere in
> the  standard lib search path
Typically, if the includes are in e.g. xxx/include/lua5.1, then the 
relative library should be in xxx/lib, i.e. if headers are installed in 
a certain prefix, then the library should be in that same prefix.

> so I set our Lua lib path to the local
> one which is a harmless duplication.
this is in particular what I do not understand: why creating a 
LUA_LIB_DIR and then set it to our local lib folder, which is not going 
to ever contain the lua library if USE_SYSTEM_LUA=1?

If we allow for an option called --with-lua-prefix then we must respect 
the prefix given by the user using it as base for both the include and 
the lib search folders.

Anyway if the current code works, there's no need to further loose time 
on it ;)

Francesco

On Jan 15, 2008 2:45 PM, Francesco Montorsi <f18...@ya...> wrote:
> John Labenski ha scritto:
>
> > On Jan 15, 2008 9:59 AM, Rob Kendrick <rj...@rj...> wrote:
> >> On Mon, 2008-01-14 at 12:07 -0500, John Labenski wrote:
> >>
> >>> Yes, if Lua is in your include paths it will try to find it and if
> >>> found will use it by default, else specify the path.
> >>>
> >> Doesn't look like it's passing /usr/include/lua5.1/ to any of the
> >> invocations of the compiler.
> >>
> >
> > Fixed now, hopefully, please try again.
> Sorry, but I don't understand this last change to configure.ac...
>
> I've modified the test and tested it under Ubuntu 7.10 with system's
> lua5.1 installed and it seems to work...
>

The Ubuntu package liblua5.1-0-dev puts the includes in
"/usr/include/lua5.1". My last commit for the bakefiles and
configure.ac was to remove the "/include" from $(LUA_DIR)/include so
you could exactly specify where the includes are.

I'm not sure we want to force "$lua_prefix/include/lua5.1" because
we're going to find someone with some system who has it elsewhere and
then we'll have more problems. It is a good idea to check
/usr/include/lua5.1 however.

# default include folder for lua 5.1 seems to be $lua_prefix/include/lua5.1
LUA_INCLUDE_DIR="$lua_prefix/include/lua5.1"
LUA_LIB_DIR="$lua_prefix/lib"

I would have kept this code, the includes can be anywhere, but the
system Lua libs should be in usr/lib or usr/local/lib or somewhere in
the  standard lib search path so I set our Lua lib path to the local
one which is a harmless duplication.

http://wxlua.cvs.sourceforge.net/wxlua/wxLua/build/autoconf/configure.ac?r1=1.64&r2=1.65

if test ! $lua_dir = ""; then 	
   LUA_INCLUDE_DIR=$lua_dir 	
   # We don't know where the system LUA_LIB_DIR is, just duplicate our
lib path
   LUA_LIB_DIR="`pwd`/lib" 	
   echo "  Lua include path: '$LUA_INCLUDE_DIR'" 	
fi

Regards,
    John