wxlua-users Mailing List for wxLua (Page 3)

Anders F Björklund ha scritto:
> Francesco Montorsi wrote:
> 
>>> Here are the issues I've run into:
>>>
>>> - Bakefile doesn't seem to support Universal Binaries, it uses the
>>>    -MMD flag which chokes the compilation
>> with which error?
> 
> gcc: -E, -S, -save-temps and -M options are not allowed with multiple 
> -arch flags
> (Universal Binaries uses "-arch ppc -arch i386" flags, to build for 
> both arches)
ahah. This is the post related to this problem (on bakefile-dev):

http://article.gmane.org/gmane.comp.sysutils.bakefile.devel/843

I've posted a reply asking Armel if he managed to fix this in bk-deps.


>>> and doesn't support the
>>>    -isysroot flag which chokes the linking.
>> hmm, are you saying that it doesn't add (by default) the -isysroot or
>> that in some way you cannot specify it at all?
> 
> The flag worked OK for the compilations, but not for linking the 
> dynamic libraries:
> shared-ld: unhandled option '-isysroot'
that is, it's a compiler flag, ok.


> (-isysroot is used when cross-compiling from one Mac OS X version over 
> to another:
> "-isysroot /Developer/SDKs/MacOSX10.4u.sdk" or 
> MacOSX{10.3.9,10.2.8,10.1.5}.sdk)
ok


>>> So building twice it is
>>>    (once for PowerPC and once for Intel, and then merging with lipo)
>> hmmm, I see the -MMD flag is added by bk-make-pch:
>>
>> # can do this because gcc is >= 3.4:
>> ${compiler} -o ${outfile} -MMD -MF "${depsfile}" "${headerfile}"
>>
>> It's used for dependency tracking.
> 
> An unrelated problem here is that you get a "no _main" when 
> cross-compiling.
> 
> I think it must be written like this, to work with Apple 
> cross-compilers:
> ${compiler} -c -o ${outfile} -MMD -MF "${depsfile}" "${headerfile}"
can you confirm that adding the "-c" fix the "no _main" problem ?
It that's the problem we should submit a bakefile patch.


>> I don't understand why it chokes your
>> compilation but I wonder if doing:
>>
>>    LDFLAGS="-isysroot" ./configure --disable-dependency-tracking
>>
>> wouldn't help you to solve these problems...
> 
> Oops, my bad... Apple actually recommends that in their notes:
> http://developer.apple.com/technotes/tn2005/tn2137.html
so, in conclusion, adding the --disable-dependency-tracking fixes the 
problem ?



>> Do you think adding the above would fix the problem?
> 
> I will experiment a little, but I'm very unfamiliar with Bakefiles.
I'll try to do some experiment, too.

I'll look at the diffs of the Makefile.in trying to look if I can get 
applications to link against versioned libraries of wxLua, i.e. the 
*-2.8.0.0.0.dylib libraries.

That is the right thing to do, isn't it?

Also, is it common on Mac to have versioned libraries named like 
*-2.8.0.0.0.dylib (5 numbers!)?


>>> - The generated program does not use Rez to set the icons, which
>>>    for wxWidgets means that they won't receive any events either.
>> sorry, I'm not sure to get what you mean here saying "events"...
> 
> They stay in the background. Menus are inactive. Windows are inactive.
> The only thing they respond to is closing the main window or quitting.
Thus, they're basically unusable.

> Not 100% sure why actually, but adding a resfork or bundle "fixes" it ?
see below


>>>    It needs to call upon Rez with the Carbon.r and wxLua.r files.
>>>    Unfortunately `wx-config --rezflags` is now gone from wx 2.8.0.
>>>    To complicate things more, the wxLua.r.gz is corrupted (ASCII?)
>> sorry, I always forgot the "-kb" flag when adding binary things to CVS.
>> See my other msg.
> 
> Np, guessed that - seemed that wxLua.icns was corrupted in the same way 
> ?
I don't have the non-corrupted version of wxLua.icns... could you send 
it to me then?

BTW I've found out that I was missing some <mac-res> in apps.bkl. I've 
added them and committed the updated Makefile.in to CVS.
Could you verify that Rez is now correctly called?

Also, I've added (this time with -kb) the file "wxlua.r" (note the 
lowercase) under wxLua\art since that's the place where we keep wxLua 
resource files.


>>> - wxStEdit seems to install the library as libstedit, but is later
>>>    trying to use it for linking with the libwx_macu_stedit name.
>> libwx_macu_stedit should be right. Are you sure are you using the 
>> latest
>> CVS for wxStEdit too?
> 
> I am certain that I am using wx 2.8.0 and wxstedit 1.2.4 (not CVS 
> versions)
John, is wxstedit 1.2.4 generating the wxlike-libname (and in this case 
there's something wrong somewhere with wxstedit's Makefile.in) or rather 
you've added this feature only in wxstedit CVS?


> It installed the headers in /usr/local/include/wx as well, instead of in
> /usr/local/include/wx-2.8/wx. But it's possible that this is fixed in 
> CVS ?
this is not a bug. This is wanted. Better not to mess with the wx's 
include folder. /usr/local/include/wx  (unversioned) is a safer place.

> Will there be a 1.2.5 release out to fix this, before wxLua 2.8.0 is 
> out ?
Good question: I'd like to see wxStEdit 1.2.5 if 1.2.4 is using 
libstedit as libname...

Francesco

Anders F Björklund ha scritto:
> Francesco Montorsi wrote:
> 
>> I don't understand exactly what needs to be done to get this, 
>> however...
>> (i.e. which is the post-process step?)
> 
> Sorry, the post-process would be either of:
> 1) Rez (Carbon.r, wxLua.r), SetFile
> 2) mkdir/cp (wxLua.icns), Info.plist
> 
> i.e. either make resource fork, or make bundle.
> This could of course easilly be scripted...
see my other mail about Rez & SetFile.
Don't know about step #2.... what does it do?
Should it go in makefiles (not so easy to do) because it's _required_ 
for getting wxLua apps to work or rather it's something related to the 
distribution/packaging process which could be scripted in a separate 
distrib/macbundle/make.sh script?


>>> Works good on Mac OS X 10.4, anyway. Looks good, too:
>>> http://www.algonet.se/~afb/wx/wxlua28-wxluasudoku.png
>> great, I've added also this screenshot (I also added the other ones you
>> posted - thanks!).
> 
> Once wxLua 2.8.0 is release, we can synchronize screenshots...
actually I forgot to update thumbnails. Done now.


>>> Of course, then one might as well wrap the program with
>>> a call to "wxlua" and not use freeze in the first place ?
>> AFAIK wxluafreeze basically just do that: i.e. wraps the user's lua
>> script with a wxlua interpreter...
> 
> Yes, but I meant wrapping it in a shell script:
> #!/bin/sh
> wxlua `dirname $0`/myprogram.wx.lua
> 
> Just so that the user has something to double-click :-)
yes, of course it could be done. But wxluafreeze has the advantage of 
not requiring an external wxlua installed (i.e. it's the equivalent of 
the Python freeze)...

Francesco

Is it possible to do a "monolithic" build of wxLua,
that would keep wxlua/wxbind/wxluasocket/wxluadebug
in just one shared library instead of four ? (as now)

i.e.
libwxlua_macu_wxlua-2.8.0.dylib
libwxlua_macu_wxbind-2.8.0.dylib
libwxlua_macu_wxluasocket-2.8.0.dylib
libwxlua_macu_wxluadebug-2.8.0.dylib
=>
libwxlua_macu-2.8.0.dylib

Easier to do a "wxLua.framework" shared Mac library
that way, and is what I am using for "wx.framework"
(also have a "lua.framework", but that is simpler)

--anders

Francesco Montorsi wrote:

>> PS. These were the Universal Binary builds (i.e. ppc+x86)
>> It requires Mac OS X 10.4 to run, can do a 10.3 build too.
> I don't know how much 10.3 is old... maybe we could "drop" support for 
> it...

Find it easier to do one build 10.4 build for PowerPC/Intel,
and one 10.3 build (that might even work on 10.2 and 10.1)

Others do the Intel part for 10.4 (as is required by the OS),
and the PowerPC part for 10.3 and then merge them together.

--anders

Francesco Montorsi wrote:

>> Here are the issues I've run into:
>>
>> - Bakefile doesn't seem to support Universal Binaries, it uses the
>>    -MMD flag which chokes the compilation
> with which error?

gcc: -E, -S, -save-temps and -M options are not allowed with multiple 
-arch flags
(Universal Binaries uses "-arch ppc -arch i386" flags, to build for 
both arches)

>> and doesn't support the
>>    -isysroot flag which chokes the linking.
> hmm, are you saying that it doesn't add (by default) the -isysroot or
> that in some way you cannot specify it at all?

The flag worked OK for the compilations, but not for linking the 
dynamic libraries:
shared-ld: unhandled option '-isysroot'

(-isysroot is used when cross-compiling from one Mac OS X version over 
to another:
"-isysroot /Developer/SDKs/MacOSX10.4u.sdk" or 
MacOSX{10.3.9,10.2.8,10.1.5}.sdk)

>> So building twice it is
>>    (once for PowerPC and once for Intel, and then merging with lipo)
> hmmm, I see the -MMD flag is added by bk-make-pch:
>
> # can do this because gcc is >= 3.4:
> ${compiler} -o ${outfile} -MMD -MF "${depsfile}" "${headerfile}"
>
> It's used for dependency tracking.

An unrelated problem here is that you get a "no _main" when 
cross-compiling.

I think it must be written like this, to work with Apple 
cross-compilers:
${compiler} -c -o ${outfile} -MMD -MF "${depsfile}" "${headerfile}"

> I don't understand why it chokes your
> compilation but I wonder if doing:
>
>    LDFLAGS="-isysroot" ./configure --disable-dependency-tracking
>
> wouldn't help you to solve these problems...

Oops, my bad... Apple actually recommends that in their notes:
http://developer.apple.com/technotes/tn2005/tn2137.html

> Do you think adding the above would fix the problem?

I will experiment a little, but I'm very unfamiliar with Bakefiles.

>> - The generated program does not use Rez to set the icons, which
>>    for wxWidgets means that they won't receive any events either.
> sorry, I'm not sure to get what you mean here saying "events"...

They stay in the background. Menus are inactive. Windows are inactive.
The only thing they respond to is closing the main window or quitting.

Not 100% sure why actually, but adding a resfork or bundle "fixes" it ?

>>    It needs to call upon Rez with the Carbon.r and wxLua.r files.
>>    Unfortunately `wx-config --rezflags` is now gone from wx 2.8.0.
>>    To complicate things more, the wxLua.r.gz is corrupted (ASCII?)
> sorry, I always forgot the "-kb" flag when adding binary things to CVS.
> See my other msg.

Np, guessed that - seemed that wxLua.icns was corrupted in the same way 
?

>> - wxStEdit seems to install the library as libstedit, but is later
>>    trying to use it for linking with the libwx_macu_stedit name.
> libwx_macu_stedit should be right. Are you sure are you using the 
> latest
> CVS for wxStEdit too?

I am certain that I am using wx 2.8.0 and wxstedit 1.2.4 (not CVS 
versions)

It installed the headers in /usr/local/include/wx as well, instead of in
/usr/local/include/wx-2.8/wx. But it's possible that this is fixed in 
CVS ?
Will there be a 1.2.5 release out to fix this, before wxLua 2.8.0 is 
out ?

--anders

Francesco Montorsi wrote:

> I don't understand exactly what needs to be done to get this, 
> however...
> (i.e. which is the post-process step?)

Sorry, the post-process would be either of:
1) Rez (Carbon.r, wxLua.r), SetFile
2) mkdir/cp (wxLua.icns), Info.plist

i.e. either make resource fork, or make bundle.
This could of course easilly be scripted...

>> Works good on Mac OS X 10.4, anyway. Looks good, too:
>> http://www.algonet.se/~afb/wx/wxlua28-wxluasudoku.png
> great, I've added also this screenshot (I also added the other ones you
> posted - thanks!).

Once wxLua 2.8.0 is release, we can synchronize screenshots...

>> Of course, then one might as well wrap the program with
>> a call to "wxlua" and not use freeze in the first place ?
> AFAIK wxluafreeze basically just do that: i.e. wraps the user's lua
> script with a wxlua interpreter...

Yes, but I meant wrapping it in a shell script:
#!/bin/sh
wxlua `dirname $0`/myprogram.wx.lua

Just so that the user has something to double-click :-)

--anders

Anders F Björklund ha scritto:
> It is working good, just needs a post-process step
> of adding a resource fork or an application bundle:
> 
> wxLuaSudoku.app/
> `-- Contents
>      |-- Info.plist
>      |-- MacOS
>      |   `-- wxLuaSudoku
>      |-- PkgInfo
>      `-- Resources
>          `-- wxLua.icns
> 
> The default static build might be a tad on the large
> side, though. Especially with wxWidgets included too:
> 
>   11M    ppc-static/wxluasudoku
>   11M    x86-static/wxluasudoku
>   22M    wxLuaSudoku.app
> 6.3M    wxLuaSudoku.zip
> 
> No UPX for Mach-O/i386 yet, as far as I know ? Think
> there is for Mach-O/ppc32 though, so there is hope...
good :)

I don't understand exactly what needs to be done to get this, however... 
(i.e. which is the post-process step?)


> Works good on Mac OS X 10.4, anyway. Looks good, too:
> http://www.algonet.se/~afb/wx/wxlua28-wxluasudoku.png
great, I've added also this screenshot (I also added the other ones you 
posted - thanks!).


> No requirements needed, since this was a static build:
> (i.e. just unzip, double-click the icon and it starts)
> 
> wxLuaSudoku.app/Contents/MacOS/wxLuaSudoku: Mach-O fat file with 2 
> architectures
> wxLuaSudoku.app/Contents/MacOS/wxLuaSudoku (for architecture ppc):      
> Mach-O executable ppc
> wxLuaSudoku.app/Contents/MacOS/wxLuaSudoku (for architecture i386):     
> Mach-O executable i386
> 
> wxLuaSudoku.app/Contents/MacOS/wxLuaSudoku:
>          
> /System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime 
> (compatibility version 1.0.0, current version 6.0.0)
>          /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 
> (compatibility version 1.0.0, current version 275.0.0)
>          /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 
> (compatibility version 2.0.0, current version 128.0.0)
>          /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 
> (compatibility version 1.0.0, current version 11.0.0)
>          /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, 
> current version 88.3.4)
>          /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit 
> (compatibility version 1.0.0, current version 1.0.0)
>          /usr/lib/libz.1.dylib (compatibility version 1.0.0, current 
> version 1.2.3)
>          /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current 
> version 5.0.0)
>          /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, 
> current version 7.4.0)
>          /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current 
> version 1.0.0)
> 
> The wx.framework and wxLua.framework shared libraries
> should help keep the wxLua overhead down to just once...
> 
> 248K    ppc-shared/wxluasudoku
> 276K    x86-shared/wxluasudoku
> 
> Of course, then one might as well wrap the program with
> a call to "wxlua" and not use freeze in the first place ?
AFAIK wxluafreeze basically just do that: i.e. wraps the user's lua 
script with a wxlua interpreter...

Francesco

Anders F Björklund ha scritto:
> Here was the error:
> ld: Undefined symbols:
> __ZNK20wxTopLevelWindowBase10GetMaxSizeEv referenced from libwxlua 
> expected to be defined in libwx
> /usr/bin/libtool: internal link edit command failed
> make[1]: *** [../lib/libwxlua_macu_wxbindstc-2.8.0.0.0.dylib] Error 1
> 
> Not sure where that came from, though, rebuilt it this morning and it 
> worked ?
> Must have forgotten to clean wxLua up properly or something silly like 
> that...
well, good news then.


> But there's still a lot of problems with Bakefile and the Universal 
> Binaries.
> (but those are probably generic, and not isolated to just the wxLua 
> building)
> 
> Sizes are much better now: (needs wxWidgets too, but)
>   44K    bin/lua
> 360K    bin/wxlua
> 360K    bin/wxluacan
> 3.0M    bin/wxluaedit
>   84K    bin/wxluafreeze
> 328K    lib/liblua5.1.0.0.0.dylib
> 7.4M    lib/libwxlua_macu_wxbind-2.8.0.0.0.dylib
> 908K    lib/libwxlua_macu_wxbindstc-2.8.0.0.0.dylib
> 400K    lib/libwxlua_macu_wxlua-2.8.0.0.0.dylib
> 392K    lib/libwxlua_macu_wxluadebug-2.8.0.0.0.dylib
> 536K    lib/libwxlua_macu_wxluasocket-2.8.0.0.0.dylib
> ====
> 4.2M    /tmp/wxlua.zip
great


> Will see if I can get the Makefile/Bakefile patch for Rez/SetFile done,
that would be even better ;)

> and do a "macbundle" script to bundle wxLuaEdit and LuaCan up as .app...
> (needs to generate a few Info.plist and such, using the 
> @PACKAGE_VERSION@
> and do some other XML bookkeeping like that - pretty much like 
> autopackage)
good, those files could go under wxLua\distrib\macbundle then.


> It does this now:
> /Developer/Tools/SetFile -t APPL ../bin/wxlua
> 
> It should do this:
> /Developer/Tools/Rez -d __DARWIN__ -t APPL Carbon.r \
> ../../apps/../distrib/macbundle/wxLua.r -o ../bin/wxlua
> /Developer/Tools/SetFile -a C -t APPL ../bin/wxlua
currently bakefile detects the "Rez" presence but nothing else:

autoconf/bakefile.m4:653:            AC_CHECK_PROG(REZ, Rez, Rez, 
/Developer/Tools/Rez)

I think bakefile/rules/makefile_macres.bkl contains what you'd need to 
modify.

> This will give a big "crossed-over" icon on Intel, but it can't be 
> helped.
> If you don't add a resource fork, it will not receive any events at 
> all...
> This procedure goes for *all* wx programs, also the ones with 
> wxluafreeze.
> For the non-commandline programs we can use bundles, like 
> "wxLuaEdit.app".
> 
> http://www.algonet.se/~afb/wx/wxlua-resfork.png (Tiger thinks it's 
> Classic)
ok, then we really need a resource fork.

Francesco

Anders F Björklund ha scritto:
>> I can do a manual build / packaging for Christmas, but I would
>> hardly state that it builds "out of the box" on Mac OS X :-)
> 
> It built OK using static linking of the various libraries.
> (using wxWidgets 2.8.0 with wxStEdit 1.2.4, and wxLua CVS)
> 
> The good news:
> http://www.algonet.se/~afb/wx/wxlua28-wxluacan.png
> http://www.algonet.se/~afb/wx/wxlua28-wxluamisc.png
> http://www.algonet.se/~afb/wx/wxlua28-wxluahello.png
good


> The bad news:
> 316K    bin/lua
>   24M    bin/wxlua
>   21M    bin/wxluacan
>   27M    bin/wxluaedit
>   21M    bin/wxluafreeze
> 512K    lib/liblua5.1.a
>   12M    lib/libwxlua_macu_wxbind-2.8.a
> 1.2M    lib/libwxlua_macu_wxbindstc-2.8.a
> 536K    lib/libwxlua_macu_wxlua-2.8.a
> 488K    lib/libwxlua_macu_wxluadebug-2.8.a
> 756K    lib/libwxlua_macu_wxluasocket-2.8.a
> ====
>   32M    wxlua.zip
huff, 32MB with release builds is a bad news.

> So I think I will have to get the dynamic linking working.
> (the above sizes were with the debugging symbols stripped)
ach, I was just going to ask you to strip the binaries... maybe "upx" 
(if it's available for Mac) could help.

> 
> --anders
> 
> PS. These were the Universal Binary builds (i.e. ppc+x86)
> It requires Mac OS X 10.4 to run, can do a 10.3 build too.
I don't know how much 10.3 is old... maybe we could "drop" support for it...

Francesco

Anders F Björklund ha scritto:
> A non-broken gzipped copy can be found at:
> http://www.algonet.se/~afb/wx/wxLua.r.gz
> 
> It should zmore as something like this:
> data 'icns' (-16455, "Item Icon") {
>          $"6963 6E73 0000 7747 4943 4E23 0000 0108"
>          ...
> 
> Having it in "clear text" in the distribution
> works with me, it needs to be gunzipped anyway.
>   12K    wxLua.r.gz
>   84K    wxLua.r
> 
> The Mac icon (128x128) looks like this:
> http://www.algonet.se/~afb/wx/wxLua.png
well, could you put an SVG like this:

    http://wxlua.sourceforge.net/images/wxlualogo.svg

in a .r file? We could then add it (gunzipped) to CVS.

Thanks,
Francesco

Anders F Björklund ha scritto:
> Francesco Montorsi:
> 
>>> Not actually using it, but will happy to give building it a try...
>> Great! Also remember us if you need some other file to generate the
>> MacBundle which is not in CVS yet. In fact, if the generation is more
>> than 2-3 commands, we may also add a script to do it under
>> distrib\macbundle (just like I do for autopackages under
>> distrib\autopackage).
> 
> Trying to build wxLua CVS (2.8.0) on wxMac 2.8.0 UNICODE/Universal.
> 
> Here are the issues I've run into:
> 
> - Bakefile doesn't seem to support Universal Binaries, it uses the
>    -MMD flag which chokes the compilation
with which error?

> and doesn't support the
>    -isysroot flag which chokes the linking. 
hmm, are you saying that it doesn't add (by default) the -isysroot or 
that in some way you cannot specify it at all?

>So building twice it is
>    (once for PowerPC and once for Intel, and then merging with lipo)
hmmm, I see the -MMD flag is added by bk-make-pch:

# can do this because gcc is >= 3.4:
${compiler} -o ${outfile} -MMD -MF "${depsfile}" "${headerfile}"

It's used for dependency tracking. I don't understand why it chokes your 
compilation but I wonder if doing:

   LDFLAGS="-isysroot" ./configure --disable-dependency-tracking

wouldn't help you to solve these problems...



> - The generated shared libraries only have versioned names, so they
>    aren't able to find eachother later when trying to run the binaries.
>    i.e. it installs *-2.8.0.0.0.dylib but looks for *-2.8.0.dylib ?
>    Symlinking these manually after installation fixes this issue...
hmmm, strange....

I just know that bakefiles use the following:

             <version>$(WXLUA_VERSION)</version>
             <so_version>$(WXLUA_SOVERSION)</so_version>
             <mac_version>$(WXLUA_MACVERSION)</mac_version>

where WXLUA_MACVERSION should be set to 1, WXLUA_SOVERSION to 0.0.0 and 
WXLUA_VERSION to 2.8.0

Maybe I should change mac_version tag to something else? Or remove it 
completely... I think I took that <mac_version> "logic" from wxWidgets 
bakefiles but now grepping for <mac_version> in wx\build\bakefiles gives 
no result. They have replaced it with:

     <set var="WXMACVERSION_CMD">
         <if cond="PLATFORM_MACOSX=='1'">
            <!-- Version can't be 0, so add 1 to it to force it to be 
non null -->
             -compatibility_version $(int(WX_AGE)+1).0 -current_version 
$(int(WX_AGE)+1).$(WX_REVISION)
         </if>
     </set>


         <!-- FIXME: until libtool scheme is implemented in bakefile -->
         <ldflags cond="FORMAT=='autoconf'">$(WXMACVERSION_CMD)</ldflags>

Do you think adding the above would fix the problem?


> - The generated program does not use Rez to set the icons, which
>    for wxWidgets means that they won't receive any events either.
sorry, I'm not sure to get what you mean here saying "events"...

>    It needs to call upon Rez with the Carbon.r and wxLua.r files.
>    Unfortunately `wx-config --rezflags` is now gone from wx 2.8.0.
>    To complicate things more, the wxLua.r.gz is corrupted (ASCII?)
sorry, I always forgot the "-kb" flag when adding binary things to CVS.
See my other msg.

> 
> - wxStEdit seems to install the library as libstedit, but is later
>    trying to use it for linking with the libwx_macu_stedit name.
libwx_macu_stedit should be right. Are you sure are you using the latest 
CVS for wxStEdit too?


>    Again, symlinking to the rescue - but it seems there are some
>    duplicated symbols (?) between libwx and libwxlua, so I think I
>    will have to rebuild the entire thing with static libraries...
> 
> I can do a manual build / packaging for Christmas, but I would
> hardly state that it builds "out of the box" on Mac OS X :-)
right. Would be nice to solve these problems before 2.8.0.0.

Francesco

It is working good, just needs a post-process step
of adding a resource fork or an application bundle:

wxLuaSudoku.app/
`-- Contents
     |-- Info.plist
     |-- MacOS
     |   `-- wxLuaSudoku
     |-- PkgInfo
     `-- Resources
         `-- wxLua.icns

The default static build might be a tad on the large
side, though. Especially with wxWidgets included too:

  11M    ppc-static/wxluasudoku
  11M    x86-static/wxluasudoku
  22M    wxLuaSudoku.app
6.3M    wxLuaSudoku.zip

No UPX for Mach-O/i386 yet, as far as I know ? Think
there is for Mach-O/ppc32 though, so there is hope...

Works good on Mac OS X 10.4, anyway. Looks good, too:
http://www.algonet.se/~afb/wx/wxlua28-wxluasudoku.png


No requirements needed, since this was a static build:
(i.e. just unzip, double-click the icon and it starts)

wxLuaSudoku.app/Contents/MacOS/wxLuaSudoku: Mach-O fat file with 2 
architectures
wxLuaSudoku.app/Contents/MacOS/wxLuaSudoku (for architecture ppc):      
Mach-O executable ppc
wxLuaSudoku.app/Contents/MacOS/wxLuaSudoku (for architecture i386):     
Mach-O executable i386

wxLuaSudoku.app/Contents/MacOS/wxLuaSudoku:
         
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime 
(compatibility version 1.0.0, current version 6.0.0)
         /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 
(compatibility version 1.0.0, current version 275.0.0)
         /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 
(compatibility version 2.0.0, current version 128.0.0)
         /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 
(compatibility version 1.0.0, current version 11.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, 
current version 88.3.4)
         /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit 
(compatibility version 1.0.0, current version 1.0.0)
         /usr/lib/libz.1.dylib (compatibility version 1.0.0, current 
version 1.2.3)
         /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current 
version 5.0.0)
         /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, 
current version 7.4.0)
         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current 
version 1.0.0)

The wx.framework and wxLua.framework shared libraries
should help keep the wxLua overhead down to just once...

248K    ppc-shared/wxluasudoku
276K    x86-shared/wxluasudoku

Of course, then one might as well wrap the program with
a call to "wxlua" and not use freeze in the first place ?

--anders

Here was the error:
ld: Undefined symbols:
__ZNK20wxTopLevelWindowBase10GetMaxSizeEv referenced from libwxlua 
expected to be defined in libwx
/usr/bin/libtool: internal link edit command failed
make[1]: *** [../lib/libwxlua_macu_wxbindstc-2.8.0.0.0.dylib] Error 1

Not sure where that came from, though, rebuilt it this morning and it 
worked ?
Must have forgotten to clean wxLua up properly or something silly like 
that...
But there's still a lot of problems with Bakefile and the Universal 
Binaries.
(but those are probably generic, and not isolated to just the wxLua 
building)

Sizes are much better now: (needs wxWidgets too, but)
  44K    bin/lua
360K    bin/wxlua
360K    bin/wxluacan
3.0M    bin/wxluaedit
  84K    bin/wxluafreeze
328K    lib/liblua5.1.0.0.0.dylib
7.4M    lib/libwxlua_macu_wxbind-2.8.0.0.0.dylib
908K    lib/libwxlua_macu_wxbindstc-2.8.0.0.0.dylib
400K    lib/libwxlua_macu_wxlua-2.8.0.0.0.dylib
392K    lib/libwxlua_macu_wxluadebug-2.8.0.0.0.dylib
536K    lib/libwxlua_macu_wxluasocket-2.8.0.0.0.dylib
====
4.2M    /tmp/wxlua.zip

Will see if I can get the Makefile/Bakefile patch for Rez/SetFile done,
and do a "macbundle" script to bundle wxLuaEdit and LuaCan up as .app...
(needs to generate a few Info.plist and such, using the 
@PACKAGE_VERSION@
and do some other XML bookkeeping like that - pretty much like 
autopackage)

It does this now:
/Developer/Tools/SetFile -t APPL ../bin/wxlua

It should do this:
/Developer/Tools/Rez -d __DARWIN__ -t APPL Carbon.r \
../../apps/../distrib/macbundle/wxLua.r -o ../bin/wxlua
/Developer/Tools/SetFile -a C -t APPL ../bin/wxlua

This will give a big "crossed-over" icon on Intel, but it can't be 
helped.
If you don't add a resource fork, it will not receive any events at 
all...
This procedure goes for *all* wx programs, also the ones with 
wxluafreeze.
For the non-commandline programs we can use bundles, like 
"wxLuaEdit.app".

http://www.algonet.se/~afb/wx/wxlua-resfork.png (Tiger thinks it's 
Classic)

--anders

John Labenski wrote:

> Is there anything wrong with the code itself? It sounds like that part
> at least works.

I think it's only 1 symbol (in Makefiles/linking), should be fixable.
(Mac OS X is a little picky about "indirect symbols", for instance)

>> It built OK using static linking of the various libraries.
>> (using wxWidgets 2.8.0 with wxStEdit 1.2.4, and wxLua CVS)
>
> I will be getting an antique mac next week to play with. I thought
> that macs could only be built staticly? There was also some issue
> about shared or multilib that didn't work with wxWidgets itself or has
> that been fixed?

No, it can be built statically and dynamically... But there are only
instructions from wxWidgets on how to be built it with static linking.

wxWidgets developers didn't want to do shared Mac libs until next year.

>> So I think I will have to get the dynamic linking working.
>> (the above sizes were with the debugging symbols stripped)
>
> Not cool. Doesn't OSX install wxWidgets already? Can we just link
> against that, even if it's not 2.8, 2.6 was pretty good and probably
> good enough for the Mac binary. What do you think about that?

Tiger shipped with 2.5.3. Leopard will supposedly ship with 2.8.0.
And I think I would rather stay clear of the Apple library versions ?

I'm using 2.6.3pl2++ for Mac OS X, and I will use 2.8.1 later on.

> Dumb question, since mac installs programs to /Applications as a
> package, does it also distribute the libs to the /Library dir for
> shared libs.

Unfortunately there are no Frameworks for wxWidgets, so it's
installed UNIX-style under /usr... (as mac-unicode-debug-2.5)

I've done some framework buids at http://www.algonet.se/~afb/wx/

--anders

On 12/21/06, Anders F Bj=F6rklund <af...@al...> wrote:
> > I can do a manual build / packaging for Christmas, but I would
> > hardly state that it builds "out of the box" on Mac OS X :-)

Is there anything wrong with the code itself? It sounds like that part
at least works.

> It built OK using static linking of the various libraries.
> (using wxWidgets 2.8.0 with wxStEdit 1.2.4, and wxLua CVS)

I will be getting an antique mac next week to play with. I thought
that macs could only be built staticly? There was also some issue
about shared or multilib that didn't work with wxWidgets itself or has
that been fixed?

> The good news:
> http://www.algonet.se/~afb/wx/wxlua28-wxluacan.png
> http://www.algonet.se/~afb/wx/wxlua28-wxluamisc.png
> http://www.algonet.se/~afb/wx/wxlua28-wxluahello.png

Cool.

> The bad news:
> 316K    bin/lua
>   24M    bin/wxlua
>   21M    bin/wxluacan
>   27M    bin/wxluaedit
>   21M    bin/wxluafreeze
> 512K    lib/liblua5.1.a
>   12M    lib/libwxlua_macu_wxbind-2.8.a
> 1.2M    lib/libwxlua_macu_wxbindstc-2.8.a
> 536K    lib/libwxlua_macu_wxlua-2.8.a
> 488K    lib/libwxlua_macu_wxluadebug-2.8.a
> 756K    lib/libwxlua_macu_wxluasocket-2.8.a
> =3D=3D=3D=3D
>   32M    wxlua.zip
>
> So I think I will have to get the dynamic linking working.
> (the above sizes were with the debugging symbols stripped)

Not cool. Doesn't OSX install wxWidgets already? Can we just link
against that, even if it's not 2.8, 2.6 was pretty good and probably
good enough for the Mac binary. What do you think about that?

Dumb question, since mac installs programs to /Applications as a
package, does it also distribute the libs to the /Library dir for
shared libs.

Regards,
    John Labenski

> I can do a manual build / packaging for Christmas, but I would
> hardly state that it builds "out of the box" on Mac OS X :-)

It built OK using static linking of the various libraries.
(using wxWidgets 2.8.0 with wxStEdit 1.2.4, and wxLua CVS)

The good news:
http://www.algonet.se/~afb/wx/wxlua28-wxluacan.png
http://www.algonet.se/~afb/wx/wxlua28-wxluamisc.png
http://www.algonet.se/~afb/wx/wxlua28-wxluahello.png

The bad news:
316K    bin/lua
  24M    bin/wxlua
  21M    bin/wxluacan
  27M    bin/wxluaedit
  21M    bin/wxluafreeze
512K    lib/liblua5.1.a
  12M    lib/libwxlua_macu_wxbind-2.8.a
1.2M    lib/libwxlua_macu_wxbindstc-2.8.a
536K    lib/libwxlua_macu_wxlua-2.8.a
488K    lib/libwxlua_macu_wxluadebug-2.8.a
756K    lib/libwxlua_macu_wxluasocket-2.8.a
====
  32M    wxlua.zip

So I think I will have to get the dynamic linking working.
(the above sizes were with the debugging symbols stripped)

--anders

PS. These were the Universal Binary builds (i.e. ppc+x86)
It requires Mac OS X 10.4 to run, can do a 10.3 build too.

A non-broken gzipped copy can be found at:
http://www.algonet.se/~afb/wx/wxLua.r.gz

It should zmore as something like this:
data 'icns' (-16455, "Item Icon") {
         $"6963 6E73 0000 7747 4943 4E23 0000 0108"
         ...

Having it in "clear text" in the distribution
works with me, it needs to be gunzipped anyway.
  12K    wxLua.r.gz
  84K    wxLua.r

The Mac icon (128x128) looks like this:
http://www.algonet.se/~afb/wx/wxLua.png

--anders

Francesco Montorsi:

>> Not actually using it, but will happy to give building it a try...
> Great! Also remember us if you need some other file to generate the
> MacBundle which is not in CVS yet. In fact, if the generation is more
> than 2-3 commands, we may also add a script to do it under
> distrib\macbundle (just like I do for autopackages under
> distrib\autopackage).

Trying to build wxLua CVS (2.8.0) on wxMac 2.8.0 UNICODE/Universal.

Here are the issues I've run into:

- Bakefile doesn't seem to support Universal Binaries, it uses the
   -MMD flag which chokes the compilation and doesn't support the
   -isysroot flag which chokes the linking. So building twice it is
   (once for PowerPC and once for Intel, and then merging with lipo)

- The generated shared libraries only have versioned names, so they
   aren't able to find eachother later when trying to run the binaries.
   i.e. it installs *-2.8.0.0.0.dylib but looks for *-2.8.0.dylib ?
   Symlinking these manually after installation fixes this issue...

- The generated program does not use Rez to set the icons, which
   for wxWidgets means that they won't receive any events either.
   It needs to call upon Rez with the Carbon.r and wxLua.r files.
   Unfortunately `wx-config --rezflags` is now gone from wx 2.8.0.
   To complicate things more, the wxLua.r.gz is corrupted (ASCII?)

- wxStEdit seems to install the library as libstedit, but is later
   trying to use it for linking with the libwx_macu_stedit name.
   Again, symlinking to the rescue - but it seems there are some
   duplicated symbols (?) between libwx and libwxlua, so I think I
   will have to rebuild the entire thing with static libraries...

I can do a manual build / packaging for Christmas, but I would
hardly state that it builds "out of the box" on Mac OS X :-)

--anders

On 12/21/06, Francesco Montorsi <f18...@ya...> wrote:
> John Labenski ha scritto:

> However mails are ok anyway ;)

Is there anything you'd like me to do? If you don't mind doing it, I
thought all that needs to be done is compiling in VC6 and getting the
inno setup working.

> > but I should be around sunday for a bit.
> ok, let's do sunday morning then. Hopefully it should be a pain-free
> process however.
>
> > I will check these in an hour.
> > VS 2005 dsw using debug lib/dll
> > VC 2003 makefile.vc release lib/dll
> good, yesterday however I tried to build with VC2003 and I've found that
> the LNK4006 problem was not solved... :(

I comes and goes or maybe I'm not paying attention sometimes? It makes
no sense to me and seems harmless, though annoying.

> > I think the C++ code is ok, there's a few things on my todo list, but
> > nothing that should get done before the release.
> good.
>
> BTW I've tried to use a bit the samples with the very latest CVS and
> I've found that some of them may need some small fixes:

I've fixed them, thanks for testing! These are a result of the
tightening up of the allowed parameters to the functions and, yes,
most of these were bugs where the variable passed to a wxLua function
was either a typo or not initialized and had a value of 'nil' which
used to translate to 0 or "". I think it's better this way since It's
very easy to forget [wx.]XXX and if you just get 0 or "" you might not
even know that there's a problem without rigorous testing.

> frm@ubuntu:~/work/wxLua/samples$ wxlua debug.wx.lua
> [Debug] 18:07:33: ./wxlua/src/wxlbind.cpp(330): assert
> "!wxlState.GetCallBaseClassFunction()" failed in
> wxLua_lua_getTableFunc(): Base class function call not reset
> Trace/breakpoint trap
>
> (choosing File->Debug)

This sample is BROKEN and I really don't have any idea what it's
supposed to do. It should be completely rewritten to more simply show
some debugging code instead of having all of the extra scribble code
which just confuses things. All it does now is popup a messagebox
telling you that it doesn't do anything. It has some interesting ideas
so I don't want to erase it and start over.

Also... and this is for later, the virtual function code needs to be
tweaked or rewritten. The error you got is a check for recursion, but
this isn't a show stopper since the error is for trying to make a
function for an object in *lua* virtual, which is quite different than
overriding a virtual function in C++ which requires you to really
sublcass it in C++. There's not much point in making virtual lua
functions since nobody but the lua code you write will ever call them.
I need to think more about this though.

Thanks
    John Labenski

klaas.holwerda ha scritto:
> Francesco Montorsi wrote:
>> Unfortunately I'm busy with wxpresets patch now...
>>   
> It looks like  its going to be a happy new year after all!! ;-)
right ;)

The even better news is that Vaclav said that early in January he plans 
to make bakefile 0.2.2 with the option-renaming patch applied!

In this way it will be possible to cleanup all the wxLua build system 
adopting the official wxpresets (after patch gets applied) and the 
official bakefile.

> I got so annoyed that i started to merge my Cmake stuff with the 
> official  Cmake FindWxWidgets right away.
> This  Cmake  preset  will be easy :-)
great!

I'll send you privately (just because it doesn't belong to a wxlua-users 
mailing list) a mail so that I can give some advices.

Francesco

Francesco Montorsi wrote:
>
> Unfortunately I'm busy with wxpresets patch now...
>   
It looks like  its going to be a happy new year after all!! ;-)
I got so annoyed that i started to merge my Cmake stuff with the 
official  Cmake FindWxWidgets right away.
This  Cmake  preset  will be easy :-)

Klaas

John Labenski ha scritto:
> On 12/21/06, Francesco Montorsi <f18...@ya...> wrote:
>> is it ok then to make wxLua 2.8.0.0 release saturday morning ?
>>
>> For doing releases I think it's better IM than emails (to solve any
>> eventual problem coming out at the last moments - they never are
>> missing); so:
>>
>>   - if you want to contact me through IM you can use my email address
>> for Yahoo messenger or fr...@ho... with MSN messenger.
>>
>>   - I'll also be available through #IRC at wxWidgets chat room.
> 
> I haven't used IM in years and I hate to say it, don't even know how
> to go about using it. 
well, if you're on Unix there's the very good "X-Chat GNOME" for IRC 
chatting which is very simple to use (until yesterday I had never used 
it but found out #wxwidgets IRC channel very easily).

However mails are ok anyway ;)

>I'll also be away on saturday for the holidays,
good holidays then!

> but I should be around sunday for a bit.
ok, let's do sunday morning then. Hopefully it should be a pain-free 
process however.

> I will check these in an hour.
> VS 2005 dsw using debug lib/dll
> VC 2003 makefile.vc release lib/dll
good, yesterday however I tried to build with VC2003 and I've found that 
the LNK4006 problem was not solved... :(


> I think the C++ code is ok, there's a few things on my todo list, but
> nothing that should get done before the release.
good.

BTW I've tried to use a bit the samples with the very latest CVS and 
I've found that some of them may need some small fixes:

rm@ubuntu:~/work/wxLua/samples$ wxlua coroutine.wx.lua
lua: Error while running chunk
wxLua: Expected a string for parameter 3, but got 'nil'.
stack traceback:
         [C]: in function 'wxTextCtrl'
         coroutine.wx.lua:47: in function 'new'
         coroutine.wx.lua:139: in function <coroutine.wx.lua:128>

(when clicking the button)


frm@ubuntu:~/work/wxLua/samples$ wxlua debug.wx.lua
[Debug] 18:07:33: ./wxlua/src/wxlbind.cpp(330): assert 
"!wxlState.GetCallBaseClassFunction()" failed in 
wxLua_lua_getTableFunc(): Base class function call not reset
Trace/breakpoint trap

(choosing File->Debug)


frm@ubuntu:~/work/wxLua/samples$ wxlua wxluasudoku.wx.lua
lua: Error while running chunk
wxLua: Expected a number for parameter 2, but got 'nil'.
stack traceback:
         [C]: in function 'AppendMenu'
         wxluasudoku.wx.lua:4874: in function 'main'
         wxluasudoku.wx.lua:5036: in main chunk

lua: Error while running chunk


at start.

Unfortunately I'm busy with wxpresets patch now...

Francesco

I that an update just now, and
It/All is oke again on linux.

Thanks,

Klaas

Francesco Montorsi wrote:
> klaas.holwerda ha scritto:
>   
>> Hi,
>>
>> Can't compile on linux. The lua.h is not found, very likely missing an 
>> include path now.
>> This is from wxlstate.h
>>     

On 12/21/06, Francesco Montorsi <f18...@ya...> wrote:
> is it ok then to make wxLua 2.8.0.0 release saturday morning ?
>
> For doing releases I think it's better IM than emails (to solve any
> eventual problem coming out at the last moments - they never are
> missing); so:
>
>   - if you want to contact me through IM you can use my email address
> for Yahoo messenger or fr...@ho... with MSN messenger.
>
>   - I'll also be available through #IRC at wxWidgets chat room.

I haven't used IM in years and I hate to say it, don't even know how
to go about using it. I'll also be away on saturday for the holidays,
but I should be around sunday for a bit.

I will check these in an hour.
VS 2005 dsw using debug lib/dll
VC 2003 makefile.vc release lib/dll

I think the C++ code is ok, there's a few things on my todo list, but
nothing that should get done before the release.

Thanks,
     John Labenski



>
> Francesco Montorsi ha scritto:
> > Hi all,
> >     is it if we try to make wxLua 2.8.0.0 release before 25 december?
> > It would be a nice Christmas gift for some of my friends which asked me
> > a nice interpreted language for GUI apps ;)
> >
> > Francesco
> >
> >
> >
> > -------------------------------------------------------------------------
> > 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
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

klaas.holwerda ha scritto:
> Hi,
> 
> Can't compile on linux. The lua.h is not found, very likely missing an 
> include path now.
> This is from wxlstate.h
are you sure you reran configure script and you're using the very latest 
CVS?

When I compile with the built-in lua configure adds an include flag like:

-I/home/frm/work/wxLua/./modules/lua/include

Also, what does the configure says after this line:

checking if Lua 5.1 is installed...

It should say "not found, falling back to the built-in lua".


Francesco