I installed wxLua through Mac Ports and it worked fine. However, I
only use wxluafreeze and it does not seem to be included.
Quoting John Labenski [EMAIL PROTECTED]:
Please see Anders response for the thread ANN wxLua 2.8.7.0 release
on Sourceforge.net about using MacPorts to compile it. It
ahlmans wrote:
I installed wxLua through Mac Ports and it worked fine. However, I
only use wxluafreeze and it does not seem to be included.
wxLuaFreeze is now enabled, in wxLua port revision 1: @2.8.7.0_1
(added the --enable-wxluafreeze-app argument to configure.args)
The stand-alone binary
John Labenski wrote:
Ran into another unexpected issue during the packaging:
install_name_tool: changing install names can't be redone for:
wxLua.app/Contents/MacOS/wxLua (for architecture i386) because larger
updated load commands do not fit (the program must be relinked)
Seems I need to
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
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
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
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
John Labenski wrote:
Anders, what do you think needs to change to make compiling on OSX run
smoothly?
Not much, maybe just need to add a little to the fixup scripts...
My preferred method of compiling both wxWidgets and wxLua is to create
a dir wxLua/config_osxud (unicode, debug) and then
Francesco Montorsi wrote:
Francesco, patch-Makefile.in ??? This is a bakefile fix, dunno how to
fix it.
Anders, why is this needed exactly?
As I understand it, it only adds an harmless rpath in the final
binaries...
Oh, the Mac OS X linker does not understand -rpath that's all:
ld:
Francesco Montorsi wrote:
But I'm unsure this is really necessary and instead I think it's nice
to
have the rpath stuff also under Mac (so that you can run binaries when
you compile wxLua before installing system-wide)...
There is a rpath of sorts in older Mac OS X too, and it can be
I've added a wxLua-devel 2.8.7.0, next to the wxLua 2.8.4.0 port.
It uses the snapshots, for testing wxLua (for a later port upgrade...)
Here are the updated patches: (it needed STC, to compile with wxStEdit)
http://trac.macports.org/projects/macports/browser/trunk/dports/
Rob Kendrick wrote:
Guessing from the file name of the download (which includes -tiger), am
I correct in assuming that the WxLua pre-built download on the website
is incompatible with Mac OS X 10.3.9?
It was built using the 10.4u SDK, so it requires 10.4 Tiger or later
(easier that way, since
Rob Kendrick wrote:
It is of course possible to build a version of wxLua that would work
on Panther too, but there hasn't been any demand for it since it's
EOL.
Gah - why does Mac stuff so frequently only run on (very) recent
versions? The only Mac hardware I have to had is an ancient
Rob Kendrick wrote:
Anyway, 10.3.9 is doable. Earlier versions would be more pain.
10.3.9 is what I'm running here - I'm led to believe it's the latest
that'll sensibly run on the hardware.
Panther is/was a great release, so you are probably right there.
(my main reason for upgrading to
John Labenski wrote:
I made a Mac build of wxLua-2.8.4.1 meanwhile, until the sources are
out.
I uploaded it to SourceForge's incoming area, as
wxlua-2.8.4.1-tiger.dmg
I'm sorry that I missed this and SF has already deleted it. Could you
upload it again and I'll post it at sourceforge.
John Labenski wrote:
I could try the bleeding edge wxwidgets and wxstedit, of course.
But I would prefer if it worked OK with 2.8.4 and 1.2.5 as well.
Ok, I have been using the svn of wxWidgets 2.8 since it seems like OSX
is still being worked on quite a bit.
Sure, but both wxWidgets 2.6.4
John Labenski wrote:
MSW Binary only release for now since the build files do not account
for the options to build the wxWidgets binding libs and which ones to
link to. Hopefully this will be fixed soon and the source code and (if
we're lucky) an OSX binary release will be made too.
I made a
John Labenski wrote:
Glad you got it working, since I have Visual Studio 2005 (the free
one) installed I already have that dll.
I guess in the future we need to compile the binaries with the old MS
Visual C 6. The newer Visual Cs have horrible dependency problems like
this.
Unfortunately
John Labenski:
This is something you override in include/wx/mac/carbon/app.h ?
wxApp::MacOpenFile(filename)
Yes
I see in src/mac/carbon/app.h they use it to open a document if there
is a wxDocManager::GetDocumentManager().
I think that is the default implementation of it, right.
Maybe we
Francesco Montorsi wrote:
(It's possible to build a version for 10.1-10.3, if required)
I don't know much about 10.1 and 10.3 but if they are old versions (as
I
suspect) I wouldn't take the burden of supporting them with binary
releases...
They are, and Mac OS X 10.5 is just around the
Made some Portfiles for Mac/DarwinPorts, to
compile wxLua (and the wxStEdit requirement)...
Trying to get them upstream to MP eventually,
but you can build them in a local Ports tree:
http://www.algonet.se/~afb/wx/wxstedit.Portfile
http://www.algonet.se/~afb/wx/wxlua.Portfile
# these four go in
Francesco Montorsi wrote:
well, it should be enough to know that Makefile.in is generated
automatically by bakefile but the configure.ac is not... so that to
regen the configure script we do:
aclocal autoconf mv configure ../..
;)
Yeah, I can it see clearly now that the lid is off :-)
Francesco Montorsi wrote:
Trying to get them upstream to MP eventually,
this would be very nice indeed
It's the same deal as with Debian or Gentoo, you
have to push it up to their central repository...
Here is what it looks like, on Mac OSX 10.4:
John Labenski wrote:
but you can build them in a local Ports tree:
http://www.algonet.se/~afb/wx/wxstedit.Portfile
http://www.algonet.se/~afb/wx/wxlua.Portfile
Where do these go in wxStEdit and wxLua? in the build dir? What are
these and what program calls and uses them? See below too...
Brian Haag wrote:
Sorry to create a new thread for this, but I just subscribed and
wanted to bump this while the topic is fresh.
New topics (like this one) in new threads sounds good to me
I'm very noob with OS X and *nix in general, but I'm comfortable
enough to use make, edit files, etc.
Francesco Montorsi wrote:
unfortunately our Mac OS X guru, Anders Bjorklund, has been
side-tracked and did
not manage to provide Mac OS X binaries for wxLua.
If you are willing to create such release, we would gladly accept it
and put it
in SF's download servers.
I've done a release for
Seems like the OpenGL detection is broken for Mac OS X:
conftest.cpp: In function 'int main()':
conftest.cpp:23: error: no matching function for call to
'wxGLContext::wxGLContext(NULL)'
/usr/local/include/wx-2.8/wx/mac/carbon/glcanvas.h:39: note: candidates
are:
Francesco Montorsi wrote:
So in the end there is no binary distribution of either wxLua or
wxWidgets,
but one needs to build it from source.
summing it up briefly for a mac-newbie like me, why isn't going to be a
binary distribution of wxWidgets for Mac? Have you been discussing
about
a
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
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
John Labenski wrote:
Is there anything wrong with the code itself? It sounds like that part
at least works.
I think it's only 1 symbol (in Makefiles/linking), should be fixable.
(Mac OS X is a little picky about indirect symbols, for instance)
It built OK using static linking of the various
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,
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
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
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
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
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
A non-broken gzipped copy can be found at:
http://www.algonet.se/~afb/wx/wxLua.r.gz
It should zmore as something like this:
data 'icns' (-16455, Item Icon) {
$6963 6E73 7747 4943 4E23 0108
...
Having it in clear text in the distribution
works with me, it needs to be
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:
Francesco Montorsi wrote:
Hi all|Anders Björklund,
is anyone out there using wxLua on a mac?
We would be glad to publish new wxLua screenshots for wxMac, and to fix
any problem with mac-bundling, if there's any, before 2.8.0.0
Not actually using it, but will happy to give building it a
John Labenski wrote:
First things first, how exactly do you compile it? I first do a cvs
checkout of wxLua, then create a dir wxLua/config_osx and run
$../configure --prefix=/Users/john/wx/wxLua/wxLua/config_osx
--disable-shared
$make
Same here, but without the prefix. (i.e. I just used
2006-10-09 John Labenski wrote:
On 10/9/06, wombat [EMAIL PROTECTED] wrote:
Ladies and gentlemen,
Has anyone successfully built wxLua on Mac OS 10.4
(which comes with wxWidgets 2.5 built in)? If so, I'd
appreciate some directions.
I have built it successfully, on Mac OS X 10.3 and now on
Will try, once SourceForge's CVS feels happier...
Did you manage to get CVS updated ?
No, and haven't contacted John yet either.
But I unpacked your snapshot to test with.
Busy week, so haven't been able to debug it.
--anders
---
This
Francesco Montorsi wrote:
Should be straight-forward to convert
Version: into a configurable value,
and put it into build/rpm/wxlua.spec.in ?
yes, sure; I'll do it.
And once it works, we can lose the Mac-patch part
that is currently included in the spec in 2 places:
Patch:
John Labenski wrote:
Will recompile wxLua with full debugging symbols enabled tomorrow, I
think.
That would be great, sorry but I can't help without some more
information. I can't imagine what could fail in
wxLuaEditorApp::OnInit, but a line number would help!
Here you go then:
Program
Francesco Montorsi wrote:
Hi,
if everyone agree, we could proceed today with release 2.6.2.0, as
expected...
Autopackage stuff and mac bundle could be not fully ready but they can
be added later.
If proceeding with release, I'll package wxLua this afternoon and then
upload it to SF
How do I get configure to respect the CXXFLAGS ?
Seems that it just replaces them with -g0 -O2 ?
(and whatever wx-config --cxxflags add, of course)
--anders
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
John Labenski wrote:
could someone give me rights shortly (after some hours uploaded
files are removed if not binded) or bind the files with a wxLua
release?
Ok, all done.
I get an empty (0-byte) file, for wxlua-2.6.2.0.tar.gz ?
--anders
Was a bit surprised, when my new Lua 5.1 was
overwritten by the old Lua 5.0.2 from wxLua...
Is there any reason why it installs lua too ?
(I only expected it to install the wxlua ones)
--anders
---
This SF.Net email is sponsored by xPML, a
Francesco Montorsi wrote:
well, wxLua embeds lua so I thought it was natural to install it.
It should probably be installed under another name, though ?
Otherwise it *will* cause conflicts.
The lua library installed won't create any conflict since it's named
something like:
Francesco Montorsi wrote:
finally I've tagged the wxLua tree and created all binary and
source packages, updated download page and created a news entry.
Just for fun, I tried downloading the .package file and installing it.
(following the instructions linked to from the download
Francesco Montorsi wrote:
You might want to do the same thing for the include dir, too... ?
the headers should not cause any conflict since they go in
$PREFIX/include/lua/include
(note the double include string in path - required for wxLua moduling
system). IIRC correctly lua puts its
Francesco Montorsi:
I've tried to link statically also expat but in the final ELF ldd
still shows expat.so.1 is needed.
Probably because wxWidgets was not compiled using autopackage's gcc
wrapper, apgcc, which cuts down dependencies... I'm going to create an
autopackage for wxWidgets but
As mentioned earlier, all that needs to be
done to support RPM building is to put a
spec file into a build/rpm directory...
Here is such a file, that I just wrote:
http://www.algonet.se/~afb/wx/wxlua.spec
(builds with: rpmbuild -ba wxlua.spec)
Should be straight-forward to convert
Version: into
What do you mean about tabs being screwed up? Could you try again, I
made a little fix to the sizing of the wxLuaConsole class so that it
uses EVT_SIZE and not virtual wxWindow::DoSetSize. Hopefully this'll
do it?
Well, eventually I got it all updated from CVS (and to wxStEdit 1.2.0)
and it
Francesco Montorsi wrote:
BTW, does your locale uses a dot or a comma or something else for
decimal point ?
Sweden uses a comma for decimal point, I think that should be in my
locale ?
(it varies a little, sometimes I use an US locale for the shell and
terminal)
If it uses something !=
Francesco Montorsi wrote:
I've updated the download page of wxLua website with mac stuff but I
sincerely don't know which description to put for it...
I'll try to help...
also the screenshots page listes Mac carbon but I'm not sure about
that.
Put Mac OS X, instead of Mac Carbon (API
Francesco Montorsi wrote:
Missed that the tabs of wxLuaEdit are screwed up :(
But it could be something minor, or upstream problem.
(i.e. no reason to say that it doesn't support wxMac)
does the wxStedit sample looks good on your Mac ?
Yes it does, so there is hope :-)
--anders
Francesco Montorsi wrote:
Yes, you can put those in there.
I've added the .icns only as you said it's the new format...
Should be plenty, but you could add both...
I really can't help.
Looking at
http://wiki.codeblocks.org/index.php?title=Compiling_Code::
John Labenski wrote:
What do you mean about tabs being screwed up?
See the screenshot, it's really really small :-)
http://wxlua.sourceforge.net/screenshots/wxlua_miscsamples_mac.png
Here is what the wxstedit C++ sample looks like:
http://www.algonet.se/~afb/wx/wxstedit.png
Could you try
John Labenski wrote:
made a little fix to the sizing of the wxLuaConsole class so that it
uses EVT_SIZE and not virtual wxWindow::DoSetSize. Hopefully this'll
do it?
Updated from CVS, but seems there are some other changes as well:
#error wxStEdit does not define its version symbols
Hi,
I've posted a patch to the SourceForge tracker
with some changes needed for wxMac compilation...
http://sourceforge.net/tracker/index.php?
func=detailaid=1444354group_id=140042atid=745326
Some of it applied to the general parts of wxLua,
it was missing a declaration and some inlines ?
Francesco Montorsi wrote:
I'm quite sure the patch is good. Unfortunately I haven't got a Mac to
test it nor John or Klaas, I think so your help is very useful!
No problem, but some of the issues encountered should
be present on all the platforms ? Especially these two:
1) wxluaedit.cpp
I made a (placeholder) Mac OS X app icon available at:
http://www.algonet.se/~afb/wx/wxLua.icns [new format]
http://www.algonet.se/~afb/wx/wxLua.r.gz [old format]
I took it from the website, looks like this:
http://www.algonet.se/~afb/wx/wxLua.png [128x128x32]
adapted from:
64 matches
Mail list logo
