[SDL] Re: Problems with the Mac projects

E. Wing ewmailing at gmail.com
Wed Sep 7 15:55:10 PDT 2005

> Date: Tue, 6 Sep 2005 23:05:25 +0200
> From: Anders F Bj?rklund 

> All of them do work, just that it's a pain to maintain them.
> If someone could come up with a neat toy to generate Xcode
> projects for all of Mac OS X 10.2, and 10.3 and 10.4 from
> a _single_ definition file - that would be a great thing.
> In the long run, a scripted build is probably better than
> relying on Xcode and PackageMaker - but it'll do for now.
> (and of course, ./configure && make && sudo make install
> works, but it doesn't as of yet build bundles / packages)

That's sounds like CMake :) Actually, they just added support for
Xcode, so it's going to start with Xcode 1.5/2.0 so we miss
pre-Panther. Also, they also lack the framework build style which is
the reason I haven't yet implemented the CMake build scripts for SDL.
They do have the .app bundle support though which is very convenient
for using SDL in a project, if not building SDL itself. I haven't had
time to try implementing the framework build process into CMake
myself. I'm hoping somebody else might be kind enough to implement it
before I do (which could be a long while :)

CMake would also solve the Visual Studio problem as well. And I think
they also do Borland, KDevelop, and some Codewarrior as well as
Makefiles. It might be worth implementing a CMake script just to get
all of these in one unified script, but I'm not yet motivated enough
to do it.

> It kinda did that by itself, as the CrashReporter fired right up...
> I'll try report both them as Radar bugs, but my experience with that as
> of lately is not very good (at all). And of course, I probably can't
> discuss it with anyone else after reporting, so it'll be "Duplicate".
> :-(

I'm not sure how good the CrashReporter is. I don't think it
automatically goes into the Radar system. I recently had a bug where I
knew which Apple employee that the bug would have to be reviewed by. I
added a hello message to him. Next time I talk to him, I'll have to
ask if he actually saw it and if it gets placed into the radar.

> Of course, it doesn't help that Xcode doesn't _have_ an "Install"
> button.
> (or at least, it didn't use to. you could do it with xcodebuild, though)
> Some dark days I think you are *supposed* to juggle it with the
> Finder...
I do know that when I was trying to create a custom IB palette, the
template provided did do the automatic install when I built. I
presumed there was a switch set differently. It was kind of convenient
for developing an IB palette so I didn't muck with the settings to
figure out which ones did it.

> But, it seems that Apple has moved to a new packaging format called
> ".dist" ?

Apple has a brand new installer for Tiger. It's supposed to give a lot
of capabilities that developers have been complaining about for years.
But I think it's Tiger only. There's also a learning curve I think. I
really do want to keep the system simple. I also don't think we really
need the capabilities of the installer.

> Might as well move to .tar.gz or .zip format then ? (lose the .dmg too)
The dmg is motivated by Apple's standard guidelines. Basically, they say, 
1) The best option is to ship as a .dmg if drag and drop is possible.
2) If drag and drop is not possible, go to Apple's installer.

I think we mostly fall into #1. While a zip would actually accomplish
the same thing, and I seriously considered doing a zip or tar.gz, I
think it's best to follow the guidelines here since Apple takes on the
burden of educating their users about .dmgs. They also have automatic
behaviors when opening a .dmg, like bringing a Finder window to the
front so the user knows what's going on. In contrast, doubling
clicking a zip does extract it, but in my personal example where I
have a cluttered desktop, I can't tell what happened because I don't
notice the new extracted folders being created. Anyway, we would take
on more burden about what to do with a zip. (Trust me, there are
enough Mac users out there that don't know what a zip or tar.gz is.
Sadly, I spend too much time educating Windows users what to do with a
zip too.)

I don't think he dmg isn't too bad of a format. It's like an ISO image
except it's in their file system format. I'm guessing it's more open
than the packaging format because I would presume it falls in the
Darwin/open source realm (though I could be wrong). Furthermore,
unlike the package script we currently have, building a .dmg is just a
1 line command much like zip/tar. So if it breaks for some reason not
much was invested in the system and it's really easy to change.

The other advantage of the .dmg is we could ultimately spruce it up
and make it look very attractive by changing the sizes and
arrangement, and putting in a background image or something. Maybe
you've seen some of the nice looking dmgs out there? They often put
text in the .dmg too which tells the user what they need to do without
making them open a README file. (Messages like "Drag me to ..."). I
haven't had time to figure out how to set this all up, but maybe
eventually. (Or find some volunteers)

> Not sure if it's "fair" to require everyone to upgrade to Tiger, but it
> is
> of course open to anyone to support the SDL project and maintain
> Panther too ?
> (Supporting the old ProjectBuilder as well, however, is something of
> pain...)

If you or anybody wants to support it, I'm sure you're welcome to.
It's just that nobody already involved really wants to do it. Keep in
mind that generally includes writing documentation and supporting
users that have problems.

> A reasonable compromise could be to support Mac OS X 10.2 - 10.4 for
> deploy,
> and Mac OS X 10.3 - 10.4 for development. Unsure about your Mac OS 9
> plans ?
> (there were Macintosh binaries built for the 1.2.9 release at least, I
> see)

The deployment sounds resonable. For development, Ryan was actually
telling me to drop Panther for Xcode support too since Xcode 2.1
breaks that support and I should have just overwritten the old Xcode
project. I left it around in case somebody needs it, but none of us
actually want to spend time supporting development on Panther. I
probably should have listened to him and just overwritten the file :)

I think Sam built the OS 9 stuff. I'm not involved on that side of
things, but I don't think it's actively maintained anymore. I think if
anything breaks with it, that's probably the end of it.


More information about the SDL mailing list