wxlua-users Mailing List for wxLua (Page 2)

Thanks for adding the new files.
    -John

On Jan 20, 2008 5:41 AM, Francesco Montorsi <f18...@ya...> wrote:
> Hi,
>     I see in your other message you already solved this but just FYI:
>
> John Labenski ha scritto:
> > Francesco, the only thing I can think of doing is adding another
> > target like below in modules/build/bakefiles/modules.bkl where we
> > compile all the sources together.
> I agree
>
> > I added the option MONOLITHIC_MODULE the same way that USE_LUAMODULE
> > was added but if I try to use cond"MONOLITHIC_MODULE='1'" in any form
> > I always get an error. I don't understand why USE_LUAMODULE works, but
> > MONOLITHIC_MODULE used in the exact same way doesn't.
> >
> > /home/john/cvs/wxLua/a/wxLua/modules/build/bakefiles/modules.bkl:301:
> > error: 'MONOLITHIC_MODULE=='0'': only weak condition allowed in this
> > context
> > [bakefile_gen] error: bakefile exited with error
> this means... well... that you're using a strong condition (a condition
> which depends from an OPTION) in a place where you can't:
>
> > Doesn't work
> >
> > <!--    <if cond="MONOLITHIC_MODULE=='0'"> -->
> >     <module id="mod_luamodule" template="wxlua" cond="SHARED=='1' and
> > USE_LUAMODULE=='1'">
> > the original code...
>
> the <if> above cannot contain strong condition as it's a child directly
> of <makefile> node. Such kind of <if> nodes only allow weak conditions
> (e.g. <if cond="FORMAT=='autoconf'">, where FORMAT is NOT an OPTION).
>
> the only type of <if> which can contain strong conditions are those
> inside <set> nodes AFAIK.
>
> > Neither does this
> >
> >     <module id="mod_luamodule" template="wxlua" cond="SHARED=='1' and
> > USE_LUAMODULE=='1' and MONOLITHIC_MODULE=='0'">
> this is strange and it should indeed work (cond attribute of target
> nodes allow strong conditions)... and infact I see in your later mail
> and in the actual version of modules.bkl this is the way you made it work ;)
>
> Francesco
>
>
>
> -------------------------------------------------------------------------
> 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
>

I think I have a lead on what the problem is. The new version of
bakefile is putting CRLF even in Linux (just LF) so CVS is getting
confused. It seems like some CVS clients, like Cygwin and Tortoise fix
them, but WinCVS doesn't.

See the new bakefile version thread.

Regards,
    John


On Jan 20, 2008 9:14 AM, Eero Pajarre <epa...@gm...> wrote:
> On Jan 20, 2008 3:53 PM, klaas.holwerda <ng...@kl...> wrote:
> > Hi,
> >
> > Same problem here.
> > This happened once before, and i believe it was something with checking
> > it in on unix etc.
> > I also use WinCVS, and getting a clean copy, the problem is already there.
> > Maybe try to remove it, and it it again, might fix it??
> >
>
> I have now everything in working condition because I fixed the files "manually".
> At least with WinCVS the repository version is "still broken".
>
> Remove/get doesn't seem to help. I have also tried that, if I fetch
> file version before
> the bakefile  0.2.3 RC2 revision, I get good files, version latter
> than that, I get bad files.
>
> Tried this couple of times, so it looks like WinCVS is quit capable of
> getting well
> formated makefiles out of the repository -- if the file date is older
> than 2008-01-15
>
>  Eero
>
>
> -------------------------------------------------------------------------
> 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
>

On Jan 20, 2008 5:51 AM, Francesco Montorsi <f18...@ya...> wrote:
> Hi,
>
> Francesco Montorsi ha scritto:
> > Besides the various bugfixes and the fact we can now use a vanilla
> > bakefile version (instead of the patched one), v0.2.3 also supports the
> > msvs2003prj format, i.e. MSVC IDE project files for vc++ 7.1.
> >
> > Is anyone using msvc 7.1? If so, we could add some "msvc7" folders next
> > to the "msvc6" and "msvc8" ones...
> In fact, I think that since also wx has partially dropped support to
> msvc6, we could remove msvc6 folders completely in favour of msvc7
> ones... what do you think?
>
> Or maybe we could do a last release with msvc6 support (maybe next to
> msvc7 one) and then remove it from HEAD/TRUNK...

I still use MSVC6 and like it, it's the only compiler in MSWin that I
use. The last I heard was that MSVC6 in wxWidgets was still supported
since Julian likes it too. I'd like to keep the MSVC6 build files
until wxWidgets removes them.

Isn't MSVC 7.1 (aka. 2003) is the last MSVC that doesn't require the
.NET runtime (the massive 50-100Mb lib whatever it's called), so it's
nice. Isn't 7.1 a nmake.exe only version? If yes, can't they just use
the MSVC6 makefiles?

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

Francesco, can you check the line endings of the makefile.vc files in
Linux? Mine are CRLF! Is this a new change for bakefile? I see that we
can use "bakefile --eol=native", but this option doesn't exist for
bakefile_gen. I think this is why people are having problems in the
makefile.vc thread.


Regards,
    John

On Jan 20, 2008 3:53 PM, klaas.holwerda <ng...@kl...> wrote:
> Hi,
>
> Same problem here.
> This happened once before, and i believe it was something with checking
> it in on unix etc.
> I also use WinCVS, and getting a clean copy, the problem is already there.
> Maybe try to remove it, and it it again, might fix it??
>

I have now everything in working condition because I fixed the files "manually".
At least with WinCVS the repository version is "still broken".

Remove/get doesn't seem to help. I have also tried that, if I fetch
file version before
the bakefile  0.2.3 RC2 revision, I get good files, version latter
than that, I get bad files.

Tried this couple of times, so it looks like WinCVS is quit capable of
getting well
formated makefiles out of the repository -- if the file date is older
than 2008-01-15

 Eero

Hi,

Same problem here.
This happened once before, and i believe it was something with checking 
it in on unix etc.
I also use WinCVS, and getting a clean copy, the problem is already there.
Maybe try to remove it, and it it again, might fix it??

Klaas

Eero Pajarre wrote:
> On Jan 18, 2008 5:49 PM, John Labenski <jla...@gm...> wrote:
>
>   
>> Humm. I don't know how to fix it since when I've verified that the
>> line endings are CRLF and then commit, CVS says that nothing has
>> changed.
>>
>>     
>
> I still suspect that your tools work in "UNIX" mode and when CRLF is stored
> by them, and then fetched by my  "Windows" mode tools the files end
> up ending CRCRLF (If checked in with Windows mode tools,  I think the
> files would be normalized to LF ending style in the repository)
>
>
>   

Hi,

Francesco Montorsi ha scritto:
> Besides the various bugfixes and the fact we can now use a vanilla 
> bakefile version (instead of the patched one), v0.2.3 also supports the 
> msvs2003prj format, i.e. MSVC IDE project files for vc++ 7.1.
> 
> Is anyone using msvc 7.1? If so, we could add some "msvc7" folders next 
> to the "msvc6" and "msvc8" ones...
In fact, I think that since also wx has partially dropped support to 
msvc6, we could remove msvc6 folders completely in favour of msvc7 
ones... what do you think?

Or maybe we could do a last release with msvc6 support (maybe next to 
msvc7 one) and then remove it from HEAD/TRUNK...

Francesco

Hi,
    I see in your other message you already solved this but just FYI:

John Labenski ha scritto:
> Francesco, the only thing I can think of doing is adding another
> target like below in modules/build/bakefiles/modules.bkl where we
> compile all the sources together.
I agree

> I added the option MONOLITHIC_MODULE the same way that USE_LUAMODULE
> was added but if I try to use cond"MONOLITHIC_MODULE='1'" in any form
> I always get an error. I don't understand why USE_LUAMODULE works, but
> MONOLITHIC_MODULE used in the exact same way doesn't.
> 
> /home/john/cvs/wxLua/a/wxLua/modules/build/bakefiles/modules.bkl:301:
> error: 'MONOLITHIC_MODULE=='0'': only weak condition allowed in this
> context
> [bakefile_gen] error: bakefile exited with error
this means... well... that you're using a strong condition (a condition 
which depends from an OPTION) in a place where you can't:

> Doesn't work
> 
> <!--    <if cond="MONOLITHIC_MODULE=='0'"> -->
>     <module id="mod_luamodule" template="wxlua" cond="SHARED=='1' and
> USE_LUAMODULE=='1'">
> the original code...

the <if> above cannot contain strong condition as it's a child directly 
of <makefile> node. Such kind of <if> nodes only allow weak conditions 
(e.g. <if cond="FORMAT=='autoconf'">, where FORMAT is NOT an OPTION).

the only type of <if> which can contain strong conditions are those 
inside <set> nodes AFAIK.

> Neither does this
> 
>     <module id="mod_luamodule" template="wxlua" cond="SHARED=='1' and
> USE_LUAMODULE=='1' and MONOLITHIC_MODULE=='0'">
this is strange and it should indeed work (cond attribute of target 
nodes allow strong conditions)... and infact I see in your later mail 
and in the actual version of modules.bkl this is the way you made it work ;)

Francesco

Sebastian Ahlman wrote:

> I was recently asked to create a small OSX app and I thought about
> creating it in wxLua since I have succesfully made an app using it
> before. When can I expect a new release for the Mac? Also, why is the
> newest version on the site not available for the Mac? Are the updates
> irrelevant on OSX?

The latest release, wxLua 2.8.4.2, was released for Windows only...
See http://sourceforge.net/project/showfiles.php?group_id=140042
But the one previous to it, 2.8.4.1, is available for Mac OS X ?
The goal is to make the next wxLua version, 2.8.7.0, available for
Mac OS X in about the same time as it is for the other platforms.
(both as a standalone download, and also available through MacPorts)

Not sure when that is, though. :-) Seems to work alright from CVS.

> When a new version for the Mac is available, will it support Unicode
> strings? Will the apps made using it run on both Tiger and Leopard?

Yes*, and yes. Most likely it'll use wxWidgets 2.8 Unicode and 10.4u 
SDK.
It will be a Universal Binary, so that it runs on both Intel and 
PowerPC.
(* strings would need to be in the UTF-8 encoding, instead of in 
MacRoman,
Lua itself only passes the 8-bit encoding on - for wxWidgets to 
handle...)

I'm using the regular wxMac configuration (includes OpenGL, internal 
libs)
and then add STC (Scintilla) and wxStEdit add-ons for more 
functionality.

> Anything else I should know about when planning the app (that will
> probably be used for mission critical tasks for a few years to come)?.

There's a few things that need to be documented and implemented,
with respect to the example IDE program and the standalone runtime
(wxLua and wxLuaFreeze) so that you can e.g. drag-and-drop files
to the program, and to make it easier to create wxLua applications.

The final size of your application depends on whether you want to bundle
all of wxLua, wxWidgets and Lua - for a "no-requirements" application.

--anders

Hi list!

I was recently asked to create a small OSX app and I thought about  
creating it in wxLua since I have succesfully made an app using it  
before. When can I expect a new release for the Mac? Also, why is the  
newest version on the site not available for the Mac? Are the updates  
irrelevant on OSX?

When a new version for the Mac is available, will it support Unicode  
strings? Will the apps made using it run on both Tiger and Leopard?  
Anything else I should know about when planning the app (that will  
probably be used for mission critical tasks for a few years to come)?.

Great work with the lib and thanks for all your work!

//Sebastian Ahlman

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Hi all,

I think so, its not a good attitude, but im having a hard work around=20
others particular projects...and i dont have a good environment test for=20
gcc or g++,,,at this time i got some errors to build wxlua so if you=20
have a  wxlua.exe compiled with  newest cvs files i  will be very=20
happy...the last binary version for windows have some bugs that make a=20
lack of compliance with my objectives, if there are someone that have=20
this please send me denebolaleite (at) hotmail (dot) com.

Thx in Advanced,,,Sorry For my Poor English!!!


_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/=

John Labenski wrote:

> Ok, this is getting a little too complicated for me.

Didn't mean to confuse you :-)

> Bottom line: Does it even make sense to write a script that after
> compilation creates a dir named wxLua.framework, copies all the bits,
> and create the links? Basically, we rewrite copydylibs.command to make
> this dir structure, similar to wxLua-2.4.1-tiger.dmg, but following
> the Framework dirs. Then... we have to worry about how and where to
> install it and the apps.

Well, the structure of the download disk image is just
*the same* as you get from the tarball - just with the
binaries already built so that you can run them directly...

> If mimicking a Framework dir structure makes sense could you suggest a
> structure you think would be good? I get the impression that the
> full-blown framework not what you think is right, but how about a
> pseudo-framework like dir structure that wraps everything, includes,
> libs, apps and the installer creates links to parts within it.

I'm not so sure about the "pseudo-framework" approach,
Python and Java uses this - and it is rather confusing.
It usually has some "compat settings" to help adopting,
but somewhere along the weirdo paths it always shows :-)

Usually you need a complex set of symlinks, to make
it look like a regular directory setup. Makes you wonder
why one wouldn't just provide those directories in the
first place, but instead make it look like a .framework ?

i.e. converting "include" and "lib" into Frameworks is OK.
Adding "bin" and "doc" and a lot of others probably isn't.

> If not, that's fine and copydylibs.command can be updated and we'll
> stick with the dir structure of wxLua-2.4.1-tiger.dmg.

This is my preferred approach, updated with any changes of course.
(i.e. make it the same structure as the wxLua source tarball has)

> Regards,
>     John
>
> ps. I responded to some things below, but it seems like there's too
> many little bits and the real question is simply "wxLua-2.4.1-tiger
> structure or some new dir structure?"

Replying below, but I would go with the old in-source layout
until you are ready to do a binary-only distribution of it ?
(such as one with just a wxLua.app and nothing else inside)
Preferrably it should match Windows and Linux distributions.

--anders

>>> Could it more easily solve the copydylibs.command problem of how to
>>> make the wxLua libs accessible?
>>
>> Using dylibs isn't really a problem, more of a design decision.
>
> You mean dir design right?

Well, dir design or packaging design or disk image design.

On Mac OS X, you can either use a .dylib or you can use
a .framework. The first is a file, the second is a bundle.
Similarly for binaries, you can either have a regular exe
or you can have an application bundle. Same end result...

So it's more of a file layout issue, than different content.
i.e. how to bundle libraries/headers and executable/data ?

> I am under the impression that the dir structure of
> wxLua-2.4.1-tiger.dmg is non-standard, but to me it looks a little bit
> like a Framework and if we just move things around inside we can just
> call it a framework.

The disk image should match the source tarball, was the idea.
I just added some pre-built Mac binaries and a folder icon...

It doesn't really use Frameworks and it doesn't use Xcode IDE.
(instead, it uses regular libraries/headers and ./configure)

>> Both wxWidgets and wxLua could be made to use framework bundles
>> instead, but so far it hasn't been worth the hassle of doing so
>> (in addition, having it conform more to one specific platform
>> doesn't really fit into the cross-platformness of wx - IMHO)
>>
>> Like
>> http://wiki.gnustep.org/index.php/
>> User_FAQ#Why_not_use_framework_bundles.3F
>
> Well, I use the term Framework loosely, I guess I'm seeing it as a way
> to package up a lot of files in a single dir in some semi-standard
> way.

That might be where the confusion lies, frameworks on Mac OS X are
similar to "dynamic libraries" on other platforms and a system term.

i.e. the content of a framework bundle follows strict guidelines,
even though some are abusing/extending it (like Python and Java)

> I don't know if we care that the binary wxLua packages are different
> in MSW, Linux, and OSX? Ideally we have an installer for MSW (or just
> a zip of *.exe, docs, and samples), Linux has rpms or debian/Ubuntu
> packages, and OSX has ??? and that's what's unclear to me.

For packages, Mac OS X comes with Installer.app and PKG packages -
but it can also use just a zip of *.exe / *.dll like on Windows.

For instance, my Code::Blocks package is just a .app in a .zip :
http://developer.berlios.de/project/showfiles.php?group_id=5358

>>> Then add links from /$prefix/include, /$prefix/lib, and I guess
>>> /Applications/wxLua.app to wxLua.framework/.../apps/wxLua.app.
>
> Like python does, these links are where we get Unix-like compatibility
> from our Framework package.

Well, Python only has semi-Unix-like compatibility - it still uses
the "framework paths" for things like os and sys which causes a
bunch of problems with software not expecting such Mac OS X paths...
For instance, add-ons are installed in /Library/Python/2.5/site-packages

--anders

Ok, this is getting a little too complicated for me.

Bottom line: Does it even make sense to write a script that after
compilation creates a dir named wxLua.framework, copies all the bits,
and create the links? Basically, we rewrite copydylibs.command to make
this dir structure, similar to wxLua-2.4.1-tiger.dmg, but following
the Framework dirs. Then... we have to worry about how and where to
install it and the apps.

If mimicking a Framework dir structure makes sense could you suggest a
structure you think would be good? I get the impression that the
full-blown framework not what you think is right, but how about a
pseudo-framework like dir structure that wraps everything, includes,
libs, apps and the installer creates links to parts within it.

If not, that's fine and copydylibs.command can be updated and we'll
stick with the dir structure of wxLua-2.4.1-tiger.dmg.

Regards,
    John

ps. I responded to some things below, but it seems like there's too
many little bits and the real question is simply "wxLua-2.4.1-tiger
structure or some new dir structure?"


On Jan 19, 2008 2:56 PM, Anders F Bj=F6rklund <af...@al...> wrote:
> John Labenski wrote:
> > I have to look into the universal build, I think there's something on
> > the wxWiki?
>
> I have no idea, have my stuff at http://www.algonet.se/~afb/wx/

Thanks, I'll check it out.

> > Someone mentioned python's Framework method which looks very useful,
> > but I cannot find any description of what a Framework is besides how
> > to create one using XCode. Is there a specification for it outside of
> > using XCode?
>
> There should be some system docs like "anatomy of a bundle" etc
> http://developer.apple.com/documentation/CoreFoundation/Conceptual/
> CFBundles
>
> > Could it more easily solve the copydylibs.command problem of how to
> > make the wxLua libs accessible?
>
> Using dylibs isn't really a problem, more of a design decision.

You mean dir design right?

I am under the impression that the dir structure of
wxLua-2.4.1-tiger.dmg is non-standard, but to me it looks a little bit
like a Framework and if we just move things around inside we can just
call it a framework.

> Both wxWidgets and wxLua could be made to use framework bundles
> instead, but so far it hasn't been worth the hassle of doing so
> (in addition, having it conform more to one specific platform
> doesn't really fit into the cross-platformness of wx - IMHO)
>
> Like
> http://wiki.gnustep.org/index.php/
> User_FAQ#Why_not_use_framework_bundles.3F

Well, I use the term Framework loosely, I guess I'm seeing it as a way
to package up a lot of files in a single dir in some semi-standard
way.

I don't know if we care that the binary wxLua packages are different
in MSW, Linux, and OSX? Ideally we have an installer for MSW (or just
a zip of *.exe, docs, and samples), Linux has rpms or debian/Ubuntu
packages, and OSX has ??? and that's what's unclear to me.

> > When we install we create
> >
> > /System/Library/Frameworks/wxLua.framework/Versions/
> >    ./Current -> 2.8.7
> >   ./2.8.7/
> >      ./bin/   : has lua executable
>
> Not sure if you actually need this ? If you do, it goes in "Tools".
>
> >      ./include/wxlua2.8.7 : has wxLua's headers
>
> This should go in "Headers", with versioning provided by "Versions".
>
> >      ./lib/wxlua2.8.7 : has wxLua's libs
>
> This should go in "wxLua", so must be one monolithic shared library.
>
> >      ./apps/ : has wxLua.app and others
>
> I think the applications should go outside of the framework bundle.
>
> >      ./docs/

To be more clear, the wxLua.framework will be just like
/System/Library/Frameworks/Python.framework or some other framework
(maybe you know another?) that makes sense.

> Again, not sure if needed. Usually provided outside of frameworks,
> but I suppose you could put some docs in there for Xcode browser.
>
> > Then add links from /$prefix/include, /$prefix/lib, and I guess
> > /Applications/wxLua.app to wxLua.framework/.../apps/wxLua.app.

Like python does, these links are where we get Unix-like compatibility
from our Framework package.

> > 1) Do we provide yes/no options for putting it into /Applications?
>
> They can also go into ~/Applications, if not having admin privileges
>
> > 2) Do we provide yes/no option for putting it into
> > /System/Library/Frameworks?
>
> This should be /Library/Frameworks, but could also be ~/Library too.
>
> > 3) Look at /Applications/iPhoto/Contents/Frameworks, since we have a
> > few apps do we instead put a link in the app to the framework?
> >     wxLua.app/Contents/Frameworks/wxLua.framework -> some good place
> > to put wxLua.framework. This is as opposed to putting the apps into
> > the wxLua.framework as above.
>
> If you put the framework in a central location, then it doesn't have
> to be bundled with each and every application... Same goes for wxMac.
> So instead of the symlink in Frameworks, you don't have to do anything.
> Normally, it will then find it along the regular framework search path.
>
> Applications / wxLua.app -> Frameworks / wxLua.framework -> wxWidgets
>
> Note that the name of the framework dictates the name of the includes,
> so if you use "wxLua.framework" you need to include <wxLua/wxlua.h>
> For instance OpenGL is normally in a directory "GL", but on the mac
> it's in a framework so all gl programs must change to <OpenGL/gl.h>

This is bad, but if we have the wxLua.framework/2.8.7/include/ and
also install to $prefix/include/wxlua2.8.7 people can use that as they
would for python.

John Labenski wrote:

> Isn't it true that wxLua has to provide our own wxWidgets libs in any
> case? While it seems nice to link to the system wxWidgets libs,
> they're very incompatible between 10.4 and 10.5 and on. We would be
> forced to use the lowest common denominator of 10.4 in terms of the
> wxLua bindings.

10.4 "Tiger" shipped with wx-2.5.3-debug, and 10.5 "Leopard" ships
with wx-2.8.4-debug and neither will ever get upgraded probably...
The system installation is more of runtime support for wxPython,
at least that's the "feeling" that I've been getting from it ?

http://www.opensource.apple.com/darwinsource/10.4/wxWidgets-2/
http://www.opensource.apple.com/darwinsource/10.4.4.x86/wxWidgets-6/

http://www.opensource.apple.com/darwinsource/10.5/wxWidgets-11/

When I was supporting 10.3 and 10.4, it was easier to build a new
since 10.3 didn't have any at all and the 10.4 one was so broken.
But I'm not sure that has changed too much, I usually build using
the 10.4u SDK now so that it'll run on both of Tiger and Leopard.

> From what I see on wx-dev, the OSX version of
> wxWidgets is much better than it was and things are getting fixed and
> added all the time. Additionally, wouldn't we have to provide wxLua
> for 10.4, 10.5 and so on instead of just a single binary which I think
> OSX people would prefer for it's simplicity.

The single binary is simple, the only downside is the 20M overhead
required for the wxWidgets library (and then some more for wxLua)
One approach is providing wxWidgets in one separate package (PKG),
and then linking the applications/libraries to this system install.

Also, I have downgraded from Leopard back to Tiger due to all the
bugs*, so I don't think I would require 10.5 for quite some time...

--anders

* and from what I've been hearing, the same goes for Vista to XP.
Supporting Mac 10.3 and Windows 2K is getting a bit old, though...

ps. I think I got it working using the method below, but with
MONOLITHIC_MODULE not giving me an error. It's a very simple change so
even if it's not the best changing it later won't be hard.

<module id="mod_luamodule" template="wxlua" cond="SHARED=='1' and
USE_LUAMODULE=='1' and MONOLITHIC_MODULE=='0'">
same as it was
...

<module id="mod_luamodule_mono" template="wxlua" cond="SHARED=='1' and
USE_LUAMODULE=='1' and MONOLITHIC_MODULE=='1'">
compile all the sources to make it monolithic
...

I will commit in an hour or so, I'm on a very slow machine and
bakefile takes forever as does compiling.

Regards,
    John


On Jan 19, 2008 3:08 PM, John Labenski <jla...@gm...> wrote:
> On Jan 17, 2008 5:24 PM, Ryan Pusztai <rpu...@gm...> wrote:
> > > > 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.)
> >
> > I agree with this. I have build files for wx.dll/so linked against the
> > monolithic wxWidgets dll/so (if it is available in wx-config for Linux) This
> > would be so great. --
>
> Francesco, the only thing I can think of doing is adding another
> target like below in modules/build/bakefiles/modules.bkl where we
> compile all the sources together.
>
> I added the option MONOLITHIC_MODULE the same way that USE_LUAMODULE
> was added but if I try to use cond"MONOLITHIC_MODULE='1'" in any form
> I always get an error. I don't understand why USE_LUAMODULE works, but
> MONOLITHIC_MODULE used in the exact same way doesn't.
>
> /home/john/cvs/wxLua/a/wxLua/modules/build/bakefiles/modules.bkl:301:
> error: 'MONOLITHIC_MODULE=='0'': only weak condition allowed in this
> context
> [bakefile_gen] error: bakefile exited with error
>
>
> ============
>
> Doesn't work
>
> <!--    <if cond="MONOLITHIC_MODULE=='0'"> -->
>     <module id="mod_luamodule" template="wxlua" cond="SHARED=='1' and
> USE_LUAMODULE=='1'">
> the original code...
>
> Neither does this
>
>     <module id="mod_luamodule" template="wxlua" cond="SHARED=='1' and
> USE_LUAMODULE=='1' and MONOLITHIC_MODULE=='0'">
>
>
> else (note that if the cond=MONOLITHID_MODULE worked
> mod_luamodule_mono would be just "mod_luamodule" replacing the above.)
>
> <!--    <if cond="MONOLITHIC_MODULE=='1'"> -->
>     <module id="mod_luamodule_mono" template="wxlua" cond="SHARED=='1'
> and USE_LUAMODULE=='1'">
>         <wxlua-dirname>$(WXLUA_LIBDIR)</wxlua-dirname>
>
>         <!-- $libdir/lua/5.1 looks to be the standard folder for lua
> modules... -->
>         <install-to>$(LIBDIR)/lua/5.1</install-to>
>
>         <include>$(WXLUA_BASEDIR)/modules/wxbind/setup</include>
>
>         <headers>$(LUAMODULE_HDR)</headers>
>         <define>WXMAKINGDLL_LUAMODULE</define>
>
>         <sources>
>             $(LUAMODULE_SRC)
>             $(WXBINDADV_SRC)
>             $(WXBINDAUI_SRC)
>             $(WXBINDBASE_SRC)
>             $(WXBINDCORE_SRC)
>             $(WXBINDGL_SRC)
>             $(WXBINDHTML_SRC)
>             $(WXBINDMEDIA_SRC)
>             $(WXBINDNET_SRC)
>             $(WXBINDRICHTEXT_SRC)
>             $(WXBINDSTC_SRC)
>             $(WXBINDXML_SRC)
>             $(WXBINDXRC_SRC)
>             $(WXLUASOCKET_SRC)
>             $(WXLUADEBUG_SRC)
>             $(WXLUA_SRC)
>         </sources>
>
>         <!-- It's important to keep the module name 'wx' to make
> require("wx") work -->
>         <dllname>wx_mono</dllname>
>
>         <!-- we won't use <wxlua-allstdlibs> because it links to the
> non-verbatim
>              version of lua, while we need the verbatim one (lua5.1.so/.dll) -->
>
>         <wxlua-lib>lua</wxlua-lib>
>
>         <wx-alllibs-req-bywxlua/>
>     </module>
>
> ==============
>
> Does this make sense?
>     John
>

On Jan 19, 2008 3:06 PM, Anders F Bj=F6rklund <af...@al...> wrote:
> Francesco Montorsi wrote:
>
> > I know wx2.8 is widely used and will last for much time; however
> > building a wx Framework for Mac is extremehely easier in wxTRUNK since
> > contribs were removed. I think that when wx3.0 will be out, it will
> > thus
> > have a wxFramework for the mac world and then building releases for
> > wx-based software for mac will be much more easier.
>
> It's not impossible to create frameworks for wx 2.6 or 2.8 either,
> the question is more whether it's a good idea and/or necessary... ?
>
> i.e. it's just as easy to include dylibs inside "MacOS" or /usr/local
> as it is to include frameworks in "Frameworks" and
> "/Library/Frameworks".
>
> > So, I don't know if it's worth the effort to spend much time in making
> > wx2.8+wxLua installation easier on Mac. Much of that work could become
> > useless for wx3.0.
>
> Assuming that wxWidgets 3.0 is actually going to be a *good* release,
> unlike the ones from two unnamed proprietary operating system
> vendors... :-P
>
> Then again, it seems that they renumbered wxWidgets 2.10 as 3.0 now,
> so I might be confused as to what goes into the next "major" release ?
>

Isn't it true that wxLua has to provide our own wxWidgets libs in any
case? While it seems nice to link to the system wxWidgets libs,
they're very incompatible between 10.4 and 10.5 and on. We would be
forced to use the lowest common denominator of 10.4 in terms of the
wxLua bindings. From what I see on wx-dev, the OSX version of
wxWidgets is much better than it was and things are getting fixed and
added all the time. Additionally, wouldn't we have to provide wxLua
for 10.4, 10.5 and so on instead of just a single binary which I think
OSX people would prefer for it's simplicity.

Regards,
    John

On Jan 17, 2008 5:24 PM, Ryan Pusztai <rpu...@gm...> wrote:
> > > 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.)
>
> I agree with this. I have build files for wx.dll/so linked against the
> monolithic wxWidgets dll/so (if it is available in wx-config for Linux) This
> would be so great. --

Francesco, the only thing I can think of doing is adding another
target like below in modules/build/bakefiles/modules.bkl where we
compile all the sources together.

I added the option MONOLITHIC_MODULE the same way that USE_LUAMODULE
was added but if I try to use cond"MONOLITHIC_MODULE='1'" in any form
I always get an error. I don't understand why USE_LUAMODULE works, but
MONOLITHIC_MODULE used in the exact same way doesn't.

/home/john/cvs/wxLua/a/wxLua/modules/build/bakefiles/modules.bkl:301:
error: 'MONOLITHIC_MODULE=='0'': only weak condition allowed in this
context
[bakefile_gen] error: bakefile exited with error


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

Doesn't work

<!--    <if cond="MONOLITHIC_MODULE=='0'"> -->
    <module id="mod_luamodule" template="wxlua" cond="SHARED=='1' and
USE_LUAMODULE=='1'">
the original code...

Neither does this

    <module id="mod_luamodule" template="wxlua" cond="SHARED=='1' and
USE_LUAMODULE=='1' and MONOLITHIC_MODULE=='0'">


else (note that if the cond=MONOLITHID_MODULE worked
mod_luamodule_mono would be just "mod_luamodule" replacing the above.)

<!--    <if cond="MONOLITHIC_MODULE=='1'"> -->
    <module id="mod_luamodule_mono" template="wxlua" cond="SHARED=='1'
and USE_LUAMODULE=='1'">
        <wxlua-dirname>$(WXLUA_LIBDIR)</wxlua-dirname>

        <!-- $libdir/lua/5.1 looks to be the standard folder for lua
modules... -->
        <install-to>$(LIBDIR)/lua/5.1</install-to>

        <include>$(WXLUA_BASEDIR)/modules/wxbind/setup</include>

        <headers>$(LUAMODULE_HDR)</headers>
        <define>WXMAKINGDLL_LUAMODULE</define>

        <sources>
            $(LUAMODULE_SRC)
            $(WXBINDADV_SRC)
            $(WXBINDAUI_SRC)
            $(WXBINDBASE_SRC)
            $(WXBINDCORE_SRC)
            $(WXBINDGL_SRC)
            $(WXBINDHTML_SRC)
            $(WXBINDMEDIA_SRC)
            $(WXBINDNET_SRC)
            $(WXBINDRICHTEXT_SRC)
            $(WXBINDSTC_SRC)
            $(WXBINDXML_SRC)
            $(WXBINDXRC_SRC)
            $(WXLUASOCKET_SRC)
            $(WXLUADEBUG_SRC)
            $(WXLUA_SRC)
        </sources>

        <!-- It's important to keep the module name 'wx' to make
require("wx") work -->
        <dllname>wx_mono</dllname>

        <!-- we won't use <wxlua-allstdlibs> because it links to the
non-verbatim
             version of lua, while we need the verbatim one (lua5.1.so/.dll) -->

        <wxlua-lib>lua</wxlua-lib>

        <wx-alllibs-req-bywxlua/>
    </module>

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

Does this make sense?
    John

Francesco Montorsi wrote:

> I know wx2.8 is widely used and will last for much time; however
> building a wx Framework for Mac is extremehely easier in wxTRUNK since
> contribs were removed. I think that when wx3.0 will be out, it will 
> thus
> have a wxFramework for the mac world and then building releases for
> wx-based software for mac will be much more easier.

It's not impossible to create frameworks for wx 2.6 or 2.8 either,
the question is more whether it's a good idea and/or necessary... ?

i.e. it's just as easy to include dylibs inside "MacOS" or /usr/local
as it is to include frameworks in "Frameworks" and 
"/Library/Frameworks".

> So, I don't know if it's worth the effort to spend much time in making
> wx2.8+wxLua installation easier on Mac. Much of that work could become
> useless for wx3.0.

Assuming that wxWidgets 3.0 is actually going to be a *good* release,
unlike the ones from two unnamed proprietary operating system 
vendors... :-P

Then again, it seems that they renumbered wxWidgets 2.10 as 3.0 now,
so I might be confused as to what goes into the next "major" release ?

--anders

On Jan 19, 2008 2:28 PM, Francesco Montorsi <f18...@ya...> wrote:
> Hi John,
>      sorry for the delay but I really had 3 intense days :)
>
> John Labenski ha scritto:
>
> > On Jan 17, 2008 8:46 PM, John Labenski <jla...@gm...> wrote:
> >>> I also added the following to the build/msw/makefile.vc
> >>>
> >>> ----------------------
> >>> # This is an advanced option. Handle with care.
> >>> # The thread model to use: use 'multi' default to allow
> >>> # multi-threading. [multi,single]
> >>> THREADING = multi
> >>> -----------------------------
> >> This is a known problem, I think it has something to do with the new
> >> version of Bakefile that we are using, but I would like Francesco to
> >> confirm it as I he is familiar with the source code for Bakefile.
> >>
> >
> > Fixed in CVS by forcing it in bakefile with
> > <set var="VARS_DONT_ELIMINATE" append="1">THREADING</set>
> > in build/bakefiles/options.bkl.
> This is the right fix; however I'd add THREADING to
> build/bakefiles/wxlua.bkl since that's the place where I already added
> (in the past) all others options which should not be pruned.
>
> NB: Moving that <set> to wxlua.bkl is ok as long as it's true that the
> THREADING option is missing only from wxLua/build/makefile* files, and
> not from modules' or apps' makefiles... is this true?

Right, that's a better place and it looks like it was was only missing
in build/msw/makefile.*.

I can't add it since I'm in the middle of trying to get monolithic to work.

Regards,
    John

John Labenski wrote:

>> I also made sure to install the OpenGL and the STC components.
>> Normally I build the regular wx libs as "monolithic", though.
>
> I have to look into the universal build, I think there's something on
> the wxWiki?

I have no idea, have my stuff at http://www.algonet.se/~afb/wx/

Using --enable-universal_binary sorta works, except that it requires
Mac OS X 10.4 or later and that it hardcodes "-arch i386 -arch ppc"
into the wx-config script so if you want to generate single arch /
native binaries later you need to hack the configuration first...

> Someone mentioned python's Framework method which looks very useful,
> but I cannot find any description of what a Framework is besides how
> to create one using XCode. Is there a specification for it outside of
> using XCode?

There should be some system docs like "anatomy of a bundle" etc
http://developer.apple.com/documentation/CoreFoundation/Conceptual/ 
CFBundles

> Could it more easily solve the copydylibs.command problem of how to
> make the wxLua libs accessible?

Using dylibs isn't really a problem, more of a design decision.

Both wxWidgets and wxLua could be made to use framework bundles
instead, but so far it hasn't been worth the hassle of doing so
(in addition, having it conform more to one specific platform
doesn't really fit into the cross-platformness of wx - IMHO)

Like  
http://wiki.gnustep.org/index.php/ 
User_FAQ#Why_not_use_framework_bundles.3F

> When we install we create
>
> /System/Library/Frameworks/wxLua.framework/Versions/
>    ./Current -> 2.8.7
>   ./2.8.7/
>      ./bin/   : has lua executable

Not sure if you actually need this ? If you do, it goes in "Tools".

>      ./include/wxlua2.8.7 : has wxLua's headers

This should go in "Headers", with versioning provided by "Versions".

>      ./lib/wxlua2.8.7 : has wxLua's libs

This should go in "wxLua", so must be one monolithic shared library.

>      ./apps/ : has wxLua.app and others

I think the applications should go outside of the framework bundle.

>      ./docs/

Again, not sure if needed. Usually provided outside of frameworks,
but I suppose you could put some docs in there for Xcode browser.

> Then add links from /$prefix/include, /$prefix/lib, and I guess
> /Applications/wxLua.app to wxLua.framework/.../apps/wxLua.app.


> 1) Do we provide yes/no options for putting it into /Applications?

They can also go into ~/Applications, if not having admin privileges

> 2) Do we provide yes/no option for putting it into  
> /System/Library/Frameworks?

This should be /Library/Frameworks, but could also be ~/Library too.

> 3) Look at /Applications/iPhoto/Contents/Frameworks, since we have a
> few apps do we instead put a link in the app to the framework?
>     wxLua.app/Contents/Frameworks/wxLua.framework -> some good place
> to put wxLua.framework. This is as opposed to putting the apps into
> the wxLua.framework as above.

If you put the framework in a central location, then it doesn't have
to be bundled with each and every application... Same goes for wxMac.
So instead of the symlink in Frameworks, you don't have to do anything.
Normally, it will then find it along the regular framework search path.

Applications / wxLua.app -> Frameworks / wxLua.framework -> wxWidgets

Note that the name of the framework dictates the name of the includes,
so if you use "wxLua.framework" you need to include <wxLua/wxlua.h>
For instance OpenGL is normally in a directory "GL", but on the mac
it's in a framework so all gl programs must change to <OpenGL/gl.h>

--anders

John Labenski ha scritto:
> 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'll have a look at this....


> 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.
seems good!

Francesco

Hi,
    I'm very ignorant on the Mac side. So take the following just as a 
weak advice :)

I know wx2.8 is widely used and will last for much time; however 
building a wx Framework for Mac is extremehely easier in wxTRUNK since 
contribs were removed. I think that when wx3.0 will be out, it will thus 
have a wxFramework for the mac world and then building releases for 
wx-based software for mac will be much more easier.

So, I don't know if it's worth the effort to spend much time in making 
wx2.8+wxLua installation easier on Mac. Much of that work could become 
useless for wx3.0.

Just my 2 cents,
Francesco


John Labenski ha scritto:
> On Jan 16, 2008 4:58 AM, Anders F Björklund <af...@al...> wrote:
>> John Labenski wrote:
> 
>> 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.
> 
> I have to look into the universal build, I think there's something on
> the wxWiki?
> 
>> 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
> 
> Someone mentioned python's Framework method which looks very useful,
> but I cannot find any description of what a Framework is besides how
> to create one using XCode. Is there a specification for it outside of
> using XCode?
> 
> Could it more easily solve the copydylibs.command problem of how to
> make the wxLua libs accessible?
> 
> When we install we create
> 
> /System/Library/Frameworks/wxLua.framework/Versions/
>    ./Current -> 2.8.7
>   ./2.8.7/
>      ./bin/   : has lua executable
>      ./include/wxlua2.8.7 : has wxLua's headers
>      ./lib/wxlua2.8.7 : has wxLua's libs
>      ./apps/ : has wxLua.app and others
>      ./docs/
> 
> Then add links from /$prefix/include, /$prefix/lib, and I guess
> /Applications/wxLua.app to wxLua.framework/.../apps/wxLua.app.
> 
> 1) Do we provide yes/no options for putting it into /Applications?
> 2) Do we provide yes/no option for putting it into /System/Library/Frameworks?
> 3) Look at /Applications/iPhoto/Contents/Frameworks, since we have a
> few apps do we instead put a link in the app to the framework?
>     wxLua.app/Contents/Frameworks/wxLua.framework -> some good place
> to put wxLua.framework. This is as opposed to putting the apps into
> the wxLua.framework as above.
> 
> 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/

Hi,

John Labenski ha scritto:
>>> In terms of wxLua going to Subversion, yes, someday. I'm sorry that
>>> I'm dragging my feet on it, but I am no expert in CVS, but I can make
>>> do. I am suspicious of svn since it appears as though you download the
>>> whole repository with a checkout which I see as a waste of disk space
>>> and when you grep for things you're inundated with garbage from the
>>> old versions.
>> This is not the case.  A subversion checkout contains no history.  What
>> it does do is keep unmodified versions of every versioned-controlled
>> file in a .svn directory for doing fast local and off-line diffs without
>> having to talk to the server.  This basically means the cost of a
>> checkout is very slightly over twice the size of the data stored in it.
>>
>> (Also, bzr branches (rather than checkouts) do include all the history,
>> which is a requirement of its distributed nature - but you can do a
>> "lightweight" checkout which is similar to an svn checkout, in that it
>> requires you to be connected to make any commits.)
>>
>>> I guess I could make a script wrapper for grep to avoid
>>> the .svn/ dirs.
I'm attaching mine ;)
Simple usage:

   $ g VARS_DONT_ELIMINATE *

God Bless The Power Of Linux and its Shell! :D

> In any case I'm not convinced that svn is any better,
>>> except that you can use the http protocol.
>> Subversion is bags quicker, has atomic commits, can version things more
>> than just files, better handling of binary files, more efficient
>> server-side storage, finer-grained and more flexible authentication and
>> permissions, vastly superior history tracking, cheap branching and is
>> still actually being maintained.  And that's just a start.
don't forget it also allows to fix once and for all the CR/CRLF problems 
which CVS messes up with (see other thread!).
With Subversion you can explicitely set the new line endings file for 
file so that the EOL will always be the same regardless of the OS/client 
the user uses for the checkout.

> Ok, I'm convinced.
> 
> After the next release I will do it, but first we need to get a
> monolithic build working and whatever else there was to do that I've
> forgotten.
right! ;)

Francesco



PS: SF allows an easy and non-painful transition; check under 
Admin->Subversion->Migration instructions

obviously it preserves the versioning history.

Hi John,
     sorry for the delay but I really had 3 intense days :)

John Labenski ha scritto:
> On Jan 17, 2008 8:46 PM, John Labenski <jla...@gm...> wrote:
>>> I also added the following to the build/msw/makefile.vc
>>>
>>> ----------------------
>>> # This is an advanced option. Handle with care.
>>> # The thread model to use: use 'multi' default to allow
>>> # multi-threading. [multi,single]
>>> THREADING = multi
>>> -----------------------------
>> This is a known problem, I think it has something to do with the new
>> version of Bakefile that we are using, but I would like Francesco to
>> confirm it as I he is familiar with the source code for Bakefile.
>>
> 
> Fixed in CVS by forcing it in bakefile with
> <set var="VARS_DONT_ELIMINATE" append="1">THREADING</set>
> in build/bakefiles/options.bkl.
This is the right fix; however I'd add THREADING to 
build/bakefiles/wxlua.bkl since that's the place where I already added 
(in the past) all others options which should not be pruned.

NB: Moving that <set> to wxlua.bkl is ok as long as it's true that the 
THREADING option is missing only from wxLua/build/makefile* files, and 
not from modules' or apps' makefiles... is this true?

Francesco

On Jan 16, 2008 4:58 AM, Anders F Bj=F6rklund <af...@al...> wrote:
> John Labenski wrote:

> My wxWidgets installation is a 10.4+ Universal Binary configuration,
> so the configure is a little (=3Dmuch) 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.

I have to look into the universal build, I think there's something on
the wxWiki?

> 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

Someone mentioned python's Framework method which looks very useful,
but I cannot find any description of what a Framework is besides how
to create one using XCode. Is there a specification for it outside of
using XCode?

Could it more easily solve the copydylibs.command problem of how to
make the wxLua libs accessible?

When we install we create

/System/Library/Frameworks/wxLua.framework/Versions/
   ./Current -> 2.8.7
  ./2.8.7/
     ./bin/   : has lua executable
     ./include/wxlua2.8.7 : has wxLua's headers
     ./lib/wxlua2.8.7 : has wxLua's libs
     ./apps/ : has wxLua.app and others
     ./docs/

Then add links from /$prefix/include, /$prefix/lib, and I guess
/Applications/wxLua.app to wxLua.framework/.../apps/wxLua.app.

1) Do we provide yes/no options for putting it into /Applications?
2) Do we provide yes/no option for putting it into /System/Library/Framewor=
ks?
3) Look at /Applications/iPhoto/Contents/Frameworks, since we have a
few apps do we instead put a link in the app to the framework?
    wxLua.app/Contents/Frameworks/wxLua.framework -> some good place
to put wxLua.framework. This is as opposed to putting the apps into
the wxLua.framework as above.

Thanks,
    John

On Fri, 2008-01-18 at 14:30 -0500, Ryan Pusztai wrote:
> On Jan 18, 2008 2:20 PM, John Labenski <jla...@gm...> wrote:
>         Ok, I'm convinced.
>         
>         After the next release I will do it, but first we need to get
>         a
>         monolithic build working and whatever else there was to do
>         that I've
>         forgotten.
> 
> Sounds good. Again I can't thank you enough for all your hard work. I
> just keep asking for things and you keep adding them. That is rare, so
> thanks!

I have to agree: since I've been using wxLua (a whole week and a half) I
can't say I've received as good and quick a response to bug reports, and
questions.  Congratulations on your efforts - they are appreciated!

B.