wxlua-users — wxLua list for users and developers

[wxlua-users] Announcing wxLua 2.8.0.0: lua bindings to wxWidgets

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

The wxLua team is pleased to announce a new release of the
lua bindings to wxWidgets cross-platform GUI library. This version 
supports wxWidgets 2.6.3 to 2.8.0 and uses lua 5.1.

wxLua is a lua scripting language wrapper around the C++ wxWidgets
cross-platform GUI library. It consists of an executable for running
standalone wxLua scripts, a module for lua programs to load using 
require, and the source code to build a library for extending C++ 
programs with a fast, small, fully embeddable scripting language.

wxWidgets is a cross-platform toolkit that lets developers create
applications for Win32, Mac OS X, GTK+, X11, Motif, WinCE, and more 
using a single codebase. Unlike other cross-platform toolkits, wxWidgets 
applications look and feel native. This is because wxWidgets uses the 
platform's own native controls rather than emulating them. It's also 
extensive, free, open-source, and mature.

wxLua wraps all the GUI controls that wxWidgets provides as well as 
common dialogs, drawing graphics, image loading, saving, manipulating, 
file functions, sound and media playback, printing, sockets, and more.


To learn more about wxLua and to download it, please visit:

   http://wxlua.sourceforge.net

To learn about wxWidgets visit:

   http://www.wxwidgets.org


Feedback greatly appreciated !

The wxLua developers

Re: [wxlua-users] release now

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

Hi,
    I finally managed to get the release done. Tagged, built binary 
releases, uploaded, updated website and posted announcements.

Hopefully we will be able to add a mac bundle soon.

Thanks to everyone and happy christmas and happy new year!
Francesco



Francesco Montorsi ha scritto:
> Hi all,
>     if there are no objects/problems I'm going to tag&release 2.8.0.0 now.
> 
> 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

[wxlua-users] release now

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

Hi all,
    if there are no objects/problems I'm going to tag&release 2.8.0.0 now.

Francesco

Re: [wxlua-users] Rez now called (was Re: wxLua on wxMac)

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

Anders F Björklund ha scritto:
> Francesco Montorsi wrote:
> 
>>>> I don't have the non-corrupted version of wxLua.icns... could you 
>>>> send
>>>> it to me then?
>>> http://www.algonet.se/~afb/wx/wxLua.icns
>>> http://www.algonet.se/~afb/wx/wxLua.r.gz
>> Ok, added .icns file with correct EOL type.
> 
> Thanks, you can change it to "wxlua.icns"
> if you prefer lower case - as long as the
> same value is in the Info.plist.in file...
ok, infact I'd like to know a thing about it:
is it something required to get wxLua working when building it (just 
like wxlua.r -- i.e. something required by mac resource system) or 
rather something used only when creating the macbundle?

In the first case it should be moved under wxLua\art (where we keep all 
resource related files); in the second one it should be kept under 
wxLua\distrib\macbundle...


>> BTW is "Rez" now correctly called?
> 
> Call seems correct, just that it operated
> on the wrong file... (a Bakefile issue ?)
right this is a bakefile bug. I've submitted a one-line fix patch.

> i.e. it did apps/wxlua, while the binary
> it should have changed is in bin/wxlua ?
> 
> Think you need a $(top_builddir)/bin prefix
should be ok now.

Thanks,
Francesco

Re: [wxlua-users] wxluafreeze apps on Mac OS X

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

Anders F Björklund ha scritto:
> Much better, just need to change a few items in Info.plist.in:
> 
> @@ -5,13 +5,13 @@
>   	<key>CFBundleInfoDictionaryVersion</key>
>   	<string>6.0</string>
>   	<key>CFBundleIdentifier</key>
> -	<string>org.wxwindows.IDENTIFIER</string>
> +	<string>net.sourceforge.wxlua.IDENTIFIER</string>
>   	<key>CFBundleDevelopmentRegion</key>
>   	<string>English</string>
>   	<key>CFBundleExecutable</key>
>   	<string>EXECUTABLE</string>
>   	<key>CFBundleIconFile</key>
> -	<string>wxmac.icns</string>
> +	<string>wxLua.icns</string>
>   	<key>CFBundleName</key>
>   	<string>EXECUTABLE</string>
>   	<key>CFBundlePackageType</key>
fixed


> And there seems to be a Bakefile problem with dependencies:
> 
> make[1]: *** No rule to make target 
> `../../distrib/macbundle/Info.plist.in/wxLua.icns', needed by 
> `app_wxlua.app/Contents/PkgInfo'.  Stop.
should be fixed


> Also, the applications currently build in apps as "apps_wxlua.app",
> they should probably be called "wxlua.app" (preferrably wxLua.app,
> if such a transformation can be set up, not sure if it's easy...)
not difficult. Should be fixed now.

Francesco

Re: [wxlua-users] Rez now called (was Re: wxLua on wxMac)

[<af...@al...>]

Francesco Montorsi wrote:

>>> I don't have the non-corrupted version of wxLua.icns... could you 
>>> send
>>> it to me then?
>>
>> http://www.algonet.se/~afb/wx/wxLua.icns
>> http://www.algonet.se/~afb/wx/wxLua.r.gz
> Ok, added .icns file with correct EOL type.

Thanks, you can change it to "wxlua.icns"
if you prefer lower case - as long as the
same value is in the Info.plist.in file...

> BTW is "Rez" now correctly called?

Call seems correct, just that it operated
on the wrong file... (a Bakefile issue ?)
i.e. it did apps/wxlua, while the binary
it should have changed is in bin/wxlua ?

Think you need a $(top_builddir)/bin prefix

--anders

Re: [wxlua-users] Rez now called (was Re: wxLua on wxMac)

[<af...@al...>]

Francesco Montorsi wrote:

> If you install things in /usr/local/include and that's not a builtin
> path for your GCC then you'll need to do:
>
> CPPFLAGS="-I/usr/local/include" ./configure

Could be a confusion with the Mac framework headers, will investigate...
i.e. <wx/wx.h> will look in 
/Library/Frameworks/wx.framework/Headers/wx.h

Doing the explicit -I is probably preferred, even it does look silly.

--anders

Re: [wxlua-users] wxluafreeze apps on Mac OS X

[<af...@al...>]

Francesco Montorsi wrote:

>> wxWidgets has it in makefiles for all the samples, for instance ?
>> (if I am not mistaken, it should also have relevant Bakefiles)
> Good idea. Looking at wx bakefiles I realized I could simply do a
> copy-and-paste of the mac_bundles.bkl file ;)
>
> I've committed an updated version of the build system and added the
> distrib/macbundle/Info.plist.in
> distrib/macbundle/wxLua.icns
> files (with correct binary type for the second).
>
> Most probably there's something still to fix to make wxLua work "out of
> the box": I obviously couldn't test the changes I've just done (i.e. I
> did them blindly). But this should be a good step.

Much better, just need to change a few items in Info.plist.in:

@@ -5,13 +5,13 @@
  	<key>CFBundleInfoDictionaryVersion</key>
  	<string>6.0</string>
  	<key>CFBundleIdentifier</key>
-	<string>org.wxwindows.IDENTIFIER</string>
+	<string>net.sourceforge.wxlua.IDENTIFIER</string>
  	<key>CFBundleDevelopmentRegion</key>
  	<string>English</string>
  	<key>CFBundleExecutable</key>
  	<string>EXECUTABLE</string>
  	<key>CFBundleIconFile</key>
-	<string>wxmac.icns</string>
+	<string>wxLua.icns</string>
  	<key>CFBundleName</key>
  	<string>EXECUTABLE</string>
  	<key>CFBundlePackageType</key>

And there seems to be a Bakefile problem with dependencies:

make[1]: *** No rule to make target 
`../../distrib/macbundle/Info.plist.in/wxLua.icns', needed by 
`app_wxlua.app/Contents/PkgInfo'.  Stop.

Also, the applications currently build in apps as "apps_wxlua.app",
they should probably be called "wxlua.app" (preferrably wxLua.app,
if such a transformation can be set up, not sure if it's easy...)

--anders

Re: [wxlua-users] compiling with wxLUA_USE_wxGLCanvas

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

I've applied a fix (well, updated it for 2.8) so it compiles now, but
I haven't checked if the wxgl lib is linked to or not. Please let us
know if it works as expected.

Regards,
    John Labenski


On 12/22/06, wx...@od... <wx...@od...> wrote:
> Hi,
>
> I get the following errors when compiling wxLua_Snapshot_2006-12-22
> with wxLUA_USE_wxGLCanvas enabled. I have enabled openGL and GLCanvas in
> wxGTK and that part seems to be working.
>
> Thanks,
> /joeyo
>
> ./wxbind/src/gdi.cpp: In function 'int wxLua_wxRect_Inside(lua_State*)':
> ./wxbind/src/gdi.cpp:806: warning: 'Inside' is deprecated (declared at
> /usr/local/include/wx-2.8/wx/gdicmn.h:486)
> ./wxbind/src/gdi.cpp: In function 'int
> wxLua_wxGLCanvas_constructor(lua_State*)':
> ./wxbind/src/gdi.cpp:10368: error: invalid conversion from 'const int*' to
> 'int*'
> ./wxbind/src/gdi.cpp:10368: error:   initializing argument 7 of
> 'wxGLCanvas::wxGLCanvas(wxWindow*, wxWindowID, const wxPoint&, const wxSize
> &, long int, const wxString&, int*, const wxPalette&)'
> ./wxbind/src/gdi.cpp: In function 'int
> wxLua_wxGLCanvasFromContext_constructor(lua_State*)':
> ./wxbind/src/gdi.cpp:10405: error: invalid conversion from 'const int*' to
> 'int*'
> ./wxbind/src/gdi.cpp:10405: error:   initializing argument 8 of
> 'wxGLCanvas::wxGLCanvas(wxWindow*, const wxGLContext*, wxWindowID, const wx
> Point&, const wxSize&, long int, const wxString&, int*, const wxPalette&)'
> ./wxbind/src/gdi.cpp: In function 'int
> wxLua_wxGLCanvasFromCCanvas_constructor(lua_State*)':
> ./wxbind/src/gdi.cpp:10442: error: invalid conversion from 'const int*' to
> 'int*'
> ./wxbind/src/gdi.cpp:10442: error:   initializing argument 8 of
> 'wxGLCanvas::wxGLCanvas(wxWindow*, const wxGLCanvas*, wxWindowID, const wxP
> oint&, const wxSize&, long int, const wxString&, int*, const wxPalette&)'
> ./wxbind/src/gdi.cpp: In function 'int
> wxLua_wxGLContext_constructor(lua_State*)':
> ./wxbind/src/gdi.cpp:10565: error: no matching function for call to
> 'wxGLContext::wxGLContext(bool&, wxGLCanvas*&, const wxPalette&)'
> /usr/local/include/wx-2.8/wx/gtk/glcanvas.h:39: note: candidates are:
> wxGLContext::wxGLContext(wxWindow*, const wxGLContext*)
> /usr/local/include/wx-2.8/wx/gtk/glcanvas.h:37: note:
> wxGLContext::wxGLContext(const wxGLContext&)
> ./wxbind/src/gdi.cpp: In function 'int
> wxLua_wxGLContextOther_constructor(lua_State*)':
> ./wxbind/src/gdi.cpp:10592: error: no matching function for call to
> 'wxGLContext::wxGLContext(bool&, wxGLCanvas*&, const wxPalette&, const
> wxGLContext*&)'
> /usr/local/include/wx-2.8/wx/gtk/glcanvas.h:39: note: candidates are:
> wxGLContext::wxGLContext(wxWindow*, const wxGLContext*)
> /usr/local/include/wx-2.8/wx/gtk/glcanvas.h:37: note:
> wxGLContext::wxGLContext(const wxGLContext&)
> ./wxbind/src/gdi.cpp: In function 'int
> wxLua_wxGLContext_GetWindow(lua_State*)':
> ./wxbind/src/gdi.cpp:10613: error: 'class wxGLContext' has no member named
> 'GetWindow'
> ./wxbind/src/gdi.cpp: In function 'int
> wxLua_wxGLContext_SetCurrent(lua_State*)':
> ./wxbind/src/gdi.cpp:10628: error: no matching function for call to
> 'wxGLContext::SetCurrent()'
> /usr/local/include/wx-2.8/wx/gtk/glcanvas.h:44: note: candidates are: void
> wxGLContext::SetCurrent(const wxGLCanvas&) const
> ./wxbind/src/gdi.cpp: In function 'int
> wxLua_wxGLContext_SetColour(lua_State*)':
> ./wxbind/src/gdi.cpp:10643: error: 'class wxGLContext' has no member named
> 'SetColour'
> ./wxbind/src/gdi.cpp: In function 'int
> wxLua_wxGLContext_SwapBuffers(lua_State*)':
> ./wxbind/src/gdi.cpp:10656: error: 'class wxGLContext' has no member named
> 'SwapBuffers'
> make[1]: *** [wxbind_dll_gdi.o] Error 1
>
> -------------------------------------------------------------------------
> 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
>

[wxlua-users] compiling with wxLUA_USE_wxGLCanvas

[<wx...@od...>]

Hi,=20

I get the following errors when compiling wxLua_Snapshot_2006-12-22
with wxLUA_USE_wxGLCanvas enabled. I have enabled openGL and GLCanvas in
wxGTK and that part seems to be working.

Thanks,
/joeyo

./wxbind/src/gdi.cpp: In function =E2=80=98int wxLua_wxRect_Inside(lua_St=
ate*)=E2=80=99:
./wxbind/src/gdi.cpp:806: warning: =E2=80=98Inside=E2=80=99 is deprecated=
 (declared at
/usr/local/include/wx-2.8/wx/gdicmn.h:486)
./wxbind/src/gdi.cpp: In function =E2=80=98int
wxLua_wxGLCanvas_constructor(lua_State*)=E2=80=99:
./wxbind/src/gdi.cpp:10368: error: invalid conversion from =E2=80=98const=
 int*=E2=80=99 to
=E2=80=98int*=E2=80=99
./wxbind/src/gdi.cpp:10368: error:   initializing argument 7 of
=E2=80=98wxGLCanvas::wxGLCanvas(wxWindow*, wxWindowID, const wxPoint&, co=
nst wxSize
&, long int, const wxString&, int*, const wxPalette&)=E2=80=99
./wxbind/src/gdi.cpp: In function =E2=80=98int
wxLua_wxGLCanvasFromContext_constructor(lua_State*)=E2=80=99:
./wxbind/src/gdi.cpp:10405: error: invalid conversion from =E2=80=98const=
 int*=E2=80=99 to
=E2=80=98int*=E2=80=99
./wxbind/src/gdi.cpp:10405: error:   initializing argument 8 of
=E2=80=98wxGLCanvas::wxGLCanvas(wxWindow*, const wxGLContext*, wxWindowID=
, const wx
Point&, const wxSize&, long int, const wxString&, int*, const wxPalette&)=
=E2=80=99
./wxbind/src/gdi.cpp: In function =E2=80=98int
wxLua_wxGLCanvasFromCCanvas_constructor(lua_State*)=E2=80=99:
./wxbind/src/gdi.cpp:10442: error: invalid conversion from =E2=80=98const=
 int*=E2=80=99 to
=E2=80=98int*=E2=80=99
./wxbind/src/gdi.cpp:10442: error:   initializing argument 8 of
=E2=80=98wxGLCanvas::wxGLCanvas(wxWindow*, const wxGLCanvas*, wxWindowID,=
 const wxP
oint&, const wxSize&, long int, const wxString&, int*, const wxPalette&)=E2=
=80=99
./wxbind/src/gdi.cpp: In function =E2=80=98int
wxLua_wxGLContext_constructor(lua_State*)=E2=80=99:
./wxbind/src/gdi.cpp:10565: error: no matching function for call to
=E2=80=98wxGLContext::wxGLContext(bool&, wxGLCanvas*&, const wxPalette&)=E2=
=80=99
/usr/local/include/wx-2.8/wx/gtk/glcanvas.h:39: note: candidates are:
wxGLContext::wxGLContext(wxWindow*, const wxGLContext*)
/usr/local/include/wx-2.8/wx/gtk/glcanvas.h:37: note:
wxGLContext::wxGLContext(const wxGLContext&)
./wxbind/src/gdi.cpp: In function =E2=80=98int
wxLua_wxGLContextOther_constructor(lua_State*)=E2=80=99:
./wxbind/src/gdi.cpp:10592: error: no matching function for call to
=E2=80=98wxGLContext::wxGLContext(bool&, wxGLCanvas*&, const wxPalette&, =
const
wxGLContext*&)=E2=80=99
/usr/local/include/wx-2.8/wx/gtk/glcanvas.h:39: note: candidates are:
wxGLContext::wxGLContext(wxWindow*, const wxGLContext*)
/usr/local/include/wx-2.8/wx/gtk/glcanvas.h:37: note:
wxGLContext::wxGLContext(const wxGLContext&)
./wxbind/src/gdi.cpp: In function =E2=80=98int
wxLua_wxGLContext_GetWindow(lua_State*)=E2=80=99:
./wxbind/src/gdi.cpp:10613: error: =E2=80=98class wxGLContext=E2=80=99 ha=
s no member named
=E2=80=98GetWindow=E2=80=99
./wxbind/src/gdi.cpp: In function =E2=80=98int
wxLua_wxGLContext_SetCurrent(lua_State*)=E2=80=99:
./wxbind/src/gdi.cpp:10628: error: no matching function for call to
=E2=80=98wxGLContext::SetCurrent()=E2=80=99
/usr/local/include/wx-2.8/wx/gtk/glcanvas.h:44: note: candidates are: voi=
d
wxGLContext::SetCurrent(const wxGLCanvas&) const
./wxbind/src/gdi.cpp: In function =E2=80=98int
wxLua_wxGLContext_SetColour(lua_State*)=E2=80=99:
./wxbind/src/gdi.cpp:10643: error: =E2=80=98class wxGLContext=E2=80=99 ha=
s no member named
=E2=80=98SetColour=E2=80=99
./wxbind/src/gdi.cpp: In function =E2=80=98int
wxLua_wxGLContext_SwapBuffers(lua_State*)=E2=80=99:
./wxbind/src/gdi.cpp:10656: error: =E2=80=98class wxGLContext=E2=80=99 ha=
s no member named
=E2=80=98SwapBuffers=E2=80=99
make[1]: *** [wxbind_dll_gdi.o] Error 1

Re: [wxlua-users] Rez now called (was Re: wxLua on wxMac)

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

Francesco Montorsi ha scritto:
> Maybe my GCC has a "builtin" search path the /usr/local/include path?
> I need to investigate.
yes, doing:

  cpp -v </dev/null

reveals that /usr/local/include is a GCC include builtin path on my 
system. OTOH, I think that in any case the configure script does not 
need modifications.

If you install things in /usr/local/include and that's not a builtin 
path for your GCC then you'll need to do:

CPPFLAGS="-I/usr/local/include" ./configure


Francesco

Re: [wxlua-users] Rez now called (was Re: wxLua on wxMac)

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

Anders F Björklund ha scritto:
> Francesco Montorsi wrote:
> 
>> 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 name of the library is "libwx_macu-2.8" (i.e. 2.8 is part of name)
> The API (major) version is 0, thus libwx_macu-2.8.0.dylib (the lib id)
> The implementation/minor version is 0.0.0, yielding all five numbers:
> 
> libwx_macu-2.8.dylib -> libwx_macu-2.8.0.dylib
> libwx_macu-2.8.0.dylib -> libwx_macu-2.8.0.0.0.dylib
> libwx_macu-2.8.0.0.0.dylib
> 
> I think it's done the same way on Linux ?
In linux the library is called e.g.

  libwxlua_gtk2u_wxlua-2.8.so.0.0.0

and there are the symlinks:

libwxlua_gtk2u_wxlua-2.8.so -> libwxlua_gtk2u_wxlua-2.8.so.0*
libwxlua_gtk2u_wxlua-2.8.so.0 -> libwxlua_gtk2u_wxlua-2.8.so.0.0.0*


> The first library/symlink
> is only for developer use, since programs link to an API version.
> (only that Macs are more sensitive to the file suffix, than Linux)
> 
> libwx_gtk2u-2.8.so -> libwx_gtk2u-2.8.so.0
> libwx_gtk2u-2.8.so.0 -> libwx_gtk2u-2.8.so.0.0.0
> libwx_gtk2u-2.8.so.0.0.0
> 
>> I don't have the non-corrupted version of wxLua.icns... could you send
>> it to me then?
> 
> http://www.algonet.se/~afb/wx/wxLua.icns
> http://www.algonet.se/~afb/wx/wxLua.r.gz
Ok, added .icns file with correct EOL type.

BTW is "Rez" now correctly called?


>> 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.
> 
> Okay, but it didn't seem to find the headers there for some reason ?
There's something I cannot understand, too.

My config.log says:

configure:7200: checking if wxStEdit (version >= 1.2.0) is available
configure:7240: g++ -o conftest  -g3 -O0 -Wall -Wundef 
-Wno-ctor-dtor-privacy 
-I/usr/local/lib/wx/include/gtk2-ansi-debug-static-2.8 
-I/usr/local/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES 
-D__WXDEBUG__ -D__WXGTK__  conftest.cpp  -lwx_gtk2d_stedit-2.8 
-L/usr/local/lib -pthread   /usr/local/lib/libwx_gtk2d_stc-2.8.a 
/usr/local/lib/libwx_gtk2d_xrc-2.8.a 
/usr/local/lib/libwx_gtk2d_html-2.8.a 
/usr/local/lib/libwx_gtk2d_adv-2.8.a 
/usr/local/lib/libwx_based_net-2.8.a 
/usr/local/lib/libwx_based_xml-2.8.a 
/usr/local/lib/libwx_gtk2d_core-2.8.a /usr/local/lib/libwx_based-2.8.a 
-lexpat -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 
-lfontconfig -lXext -lXrender -lXi -lXrandr -lXcursor -lXfixes 
-lpango-1.0 -lX11 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 
-lXinerama -lSM -lpng -ljpeg -ltiff -lz -ldl -lm  >&5
configure:7246: $? = 0

i.e. it manages to find stedit.h even without the -I/usr/local/include 
line... and I'm sure that I have stedit.h installed only at:

/usr/local/include/wx/stedit/stedit.h

and I have no symlinks that from "wx-2.8" go into "wx"... very strange.

Maybe my GCC has a "builtin" search path the /usr/local/include path?
I need to investigate.

Francesco

Re: [wxlua-users] wxluafreeze apps on Mac OS X

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

Anders F Björklund ha scritto:
> Francesco Montorsi wrote:
> 
>>> 2) mkdir/cp (wxLua.icns), Info.plist
>>>
>> 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?
> 
> It's required for the app to work properly (and is recommend for
> being more future-savvy than what the deprecated resforks are...)
> 
> The directories are just to create, nothing special about those.
> "Info.plist" is an XML plist, that follows a certain Apple DTD.
> 
> wxWidgets has it in makefiles for all the samples, for instance ?
> (if I am not mistaken, it should also have relevant Bakefiles)
Good idea. Looking at wx bakefiles I realized I could simply do a 
copy-and-paste of the mac_bundles.bkl file ;)

I've committed an updated version of the build system and added the

distrib/macbundle/Info.plist.in
distrib/macbundle/wxLua.icns

files (with correct binary type for the second).

Most probably there's something still to fix to make wxLua work "out of 
the box": I obviously couldn't test the changes I've just done (i.e. I 
did them blindly). But this should be a good step.


Francesco

Re: [wxlua-users] wxluafreeze apps on Mac OS X

[<af...@al...>]

Francesco Montorsi wrote:

>> 2) mkdir/cp (wxLua.icns), Info.plist
>>
> 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?

It's required for the app to work properly (and is recommend for
being more future-savvy than what the deprecated resforks are...)

The directories are just to create, nothing special about those.
"Info.plist" is an XML plist, that follows a certain Apple DTD.

wxWidgets has it in makefiles for all the samples, for instance ?
(if I am not mistaken, it should also have relevant Bakefiles)

Mac OS X uses similar bundles for shared libraries and packages.
(those would be the .framework and .pkg bundles, see elsewhere)

--anders

Re: [wxlua-users] Rez now called (was Re: wxLua on wxMac)

[<af...@al...>]

Francesco Montorsi wrote:

> 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 name of the library is "libwx_macu-2.8" (i.e. 2.8 is part of name)
The API (major) version is 0, thus libwx_macu-2.8.0.dylib (the lib id)
The implementation/minor version is 0.0.0, yielding all five numbers:

libwx_macu-2.8.dylib -> libwx_macu-2.8.0.dylib
libwx_macu-2.8.0.dylib -> libwx_macu-2.8.0.0.0.dylib
libwx_macu-2.8.0.0.0.dylib

I think it's done the same way on Linux ? The first library/symlink
is only for developer use, since programs link to an API version.
(only that Macs are more sensitive to the file suffix, than Linux)

libwx_gtk2u-2.8.so -> libwx_gtk2u-2.8.so.0
libwx_gtk2u-2.8.so.0 -> libwx_gtk2u-2.8.so.0.0.0
libwx_gtk2u-2.8.so.0.0.0

> I don't have the non-corrupted version of wxLua.icns... could you send
> it to me then?

http://www.algonet.se/~afb/wx/wxLua.icns
http://www.algonet.se/~afb/wx/wxLua.r.gz

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

Okay, but it didn't seem to find the headers there for some reason ?

--anders

Re: [wxlua-users] Monolithic build of wxLua ?

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

Anders F Björklund ha scritto:
> 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)
No, currently that's not possible.


> 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)
The problem is that the "monolithic" build mode is a bit of a pain to 
implement correctly... also, that's the "deprecated" build mode of 
wxWidgets since it kills the multilib logic and thus I don't think we 
will ever add it to wxLua.

I understand that this may make framework building somewhat more 
difficult but once you script it once, it will be forever :D

Francesco

[wxlua-users] Rez now called (was Re: wxLua on wxMac)

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

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

Re: [wxlua-users] wxluafreeze apps on Mac OS X

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

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

[wxlua-users] Monolithic build of wxLua ?

[<af...@al...>]

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

Re: [wxlua-users] wxLua on wxMac

[<af...@al...>]

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

Re: [wxlua-users] wxLua on wxMac

[<af...@al...>]

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

Re: [wxlua-users] wxluafreeze apps on Mac OS X

[<af...@al...>]

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

Re: [wxlua-users] wxluafreeze apps on Mac OS X

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

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

Re: [wxlua-users] Mac link error fixed / Mac resources

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

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

Re: [wxlua-users] wxLua on wxMac

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

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