I’m starting to work on the Mac OS X port, and one obvious problem
showed up right away; config.guess and config.sub are out of date.
The master copies of those files live at subversions.gnu.org,
in a three-file module named “config”; you can see them at
http://subversions.gnu.org/cgi-bin/cvsweb/config/
The files change regularly as new system info comes in, so for
the long term it would be a good idea to have a real checkout
of these modules, and update SDL from them every month or so,
or least just before releases.
Also, configure.in looks for --macos*, but since the OS X kernel
is based on Darwin, the latest config.guess reports the machine as
"powerpc-apple-darwin1.1" (yes, this is deliberate), so there needs
to be a case for --darwin*. Given all the differences in OS X,
I’m going to make it a separate case at the level of irix, beos, etc.
That’s good enough to get me started on the fun task of
Carbonization (InitGraf? There’s no InitGraf! What do you
think this is, the Mac toolbox? 
).
Stan
The master copies of those files live at subversions.gnu.org,
in a three-file module named “config”; you can see them at
http://subversions.gnu.org/cgi-bin/cvsweb/config/
Thanks, I’ll check that out!
Also, configure.in looks for --macos*, but since the OS X kernel
is based on Darwin, the latest config.guess reports the machine as
"powerpc-apple-darwin1.1" (yes, this is deliberate), so there needs
to be a case for --darwin*. Given all the differences in OS X,
I’m going to make it a separate case at the level of irix, beos, etc.
Sounds good.
That’s good enough to get me started on the fun task of
Carbonization (InitGraf? There’s no InitGraf! What do you
think this is, the Mac toolbox? ).
Is carbon the appropriate API for this? Would it make sense to use
the MacOS X native graphics API (the equivalent of X?), or is that
Carbon itself?
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Sam Lantinga wrote:
Is carbon the appropriate API for this? Would it make sense to use
the MacOS X native graphics API (the equivalent of X?), or is that
Carbon itself?
Carbon is a subset of the Mac toolbox, said to include “70%” of the
old toolbox calls. They don’t mess around either, the missing 30%
are ifdefed out of the universal headers, so we get to ifdef our
source code too. Hmmm, I think I now work in the same building
as the perpetrator of that idea, hmmm, hmmm…
There is a level called “CoreGraphics” that I think is shared between
Cocoa and Carbon, but I don’t know a lot about it yet, I just see it
mentioned in the OS X build logs… (It’s cool to have access to all
the sources, but alas, not enough hours in the day to read them 
)
It’s possible that CoreGraphics will have an API available to developers
and would make a more efficient API, but since I’m doing this for
MacHack next week, I’m just going to focus on Carbon for the moment.
Stan
It’s possible that CoreGraphics will have an API available to developers
and would make a more efficient API, but since I’m doing this for
MacHack next week, I’m just going to focus on Carbon for the moment.
Sounds good. Have fun at MacHack next week, I’m looking forward to
updates on the list. Is it possible to send a few “ground-zero” updates
from the MacHack floor so we can get a vicarious vision of it?
See ya!
-Sam Lantinga, ex-MtG addict, damn WoTC.