News:

As usual while waiting for the next release - don't forget to check the nightly builds in the forum.

Main Menu

Mac?

Started by per_eckerdal, July 10, 2005, 09:00:58 PM

Previous topic - Next topic

per_eckerdal

Hi!
Just a question out of curiousity: I was just wondering how much is needed for a mac port? Mac OS X is my preferred OS, so support would be pretty neat..

(This post DOES NOT imply that I'm going to code a port, there is a possibility, but don't count on it ;) And i dunno if you even WANT one.. hehe)
/Per Eckerdal

David Perfors

Probably some code has to be changed, but I don't know what.

I am not able to do it, because I don't have a mac :)
OS: winXP
Compiler: mingw
IDE: Code::Blocks SVN WX: 2.8.4 Wish list: faster code completion, easier debugging, refactoring

per_eckerdal


per_eckerdal

(what I wondered was mostly if you used any library that does not exist for mac..)
/Per Eckerdal

David Perfors

I can't think of one, TinyXML is compiled by us, wxwidgets is still available, I thought that was all...
OS: winXP
Compiler: mingw
IDE: Code::Blocks SVN WX: 2.8.4 Wish list: faster code completion, easier debugging, refactoring

mandrav

The most important goal of C::B is portability across platforms. Because of this, external dependencies are kept to a minimum.
To build C::B you need wxWidgets, STC (in wxWidgets contrib) and TinyXML (included).
I don't own a Mac to try it but I guess that it would build succesfully as it is now. I mean, if wxWidgets is available for Mac, I see no reason for C::B to fail compiling there.

Yiannis.
Be patient!
This bug will be fixed soon...

per_eckerdal

(Sorry to disappoint you but, :roll:)
I don't think it will work. OS X 10.4 (the latest version) uses GCC 4 and it is very picky with casts. If you haven't tested with that compiler it will probably not compile.. Most projects aren't very hard to port, tho.
/Per Eckerdal

mandrav

QuoteMost projects aren't very hard to port, tho.
That's what 's important. The point is that it will require minor modifications to work, or so I 'm told...

Yiannis.
Be patient!
This bug will be fixed soon...

Profic

AFAIR Scintilla itself didn't have port to mac...
Not fear, nor tears can reach me now, the light seems so clear as the night fades away (c) Tristania - Beyond The Veil

mandrav

Quote from: ProficAFAIR Scintilla itself didn't have port to mac...
It seems you remember wrong.
Search in that link for Mac support.

Yiannis.

PS: I 've never worked with a Mac. Everything I say about it, comes from what I read...
Be patient!
This bug will be fixed soon...

per_eckerdal

@mandrav:
My impression of Mac is that it is a relatively stable platform, though not even close to the maturity of linux or windows. The reason I use mac is mac mini, because I need to move my computer around and can't afford a laptop..

MB I should install Gentoo PPC.. (Gentoo rocks.. :))
/Per Eckerdal

per_eckerdal

.. and it is severely lacking a good ide :)..

per_eckerdal

Now I'm trying to compile Code::Blocks (CVS HEAD, wxWidgets 2.6.1 non-unicode)
There are very many wxChar* <=> char* cast errors. Should I just do (wxChar*), or should I use _() _T(). (I read your discussion about unicode..)
/Per Eckerdal

mandrav

Quote from: per_eckerdalNow I'm trying to compile Code::Blocks (CVS HEAD, wxWidgets 2.6.1 non-unicode)
There are very many wxChar* <=> char* cast errors. Should I just do (wxChar*), or should I use _() _T(). (I read your discussion about unicode..)
/Per Eckerdal
If it fixes the errors, use _() for translatable text and _T() for not translatable (like config options etc).
Then submit a patch ;)

Yiannis.
Be patient!
This bug will be fixed soon...

per_eckerdal

can the _( macro be used for other non-""'s also, e.g. _(fname.GetPath())?
Or should normal casts be used?

EDIT: The answer is no, the _() macro just adds a L to the beginning L"string" for unicode