[SDL] SDL and multiwindow project...

Marcin Kawelski kardigen at o2.pl
Wed Sep 21 00:03:18 PDT 2005


E. Wing wrote:

>> 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.
>
> 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 :)

It shouldn't be harder to do "convert" a library into a .framework,
then converting an executable into an .app bundle. Just different ?

Of course, that doesn't help with converting *from* old Xcode / PB,
so all changes need then be made in the CMake/whichever new system ?

I'll take a peek at CMake, but not so fond of Yet Another Build 
System...
(maybe I will wait for your CMake script for building SDL first, though)

Q: Would that change be for all of SDL, or just for the Mac OS X builds 
?

> 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.

Well, I've been locked out of Radar for 5 months but just got back in...
Fired quite a few bugs on RadarWeb itself, since the WebObjects rewrite.

I'm thinking they knew about most of this, when they rushed Tiger out ?

> 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.

I haven't seen much of these new features yet, just the new file 
formats.
Maybe it'll support upgrades and uninstalls and queries, Real Soon Now 
:-)

> 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.

The DMG (gzipped HFS+) is not a bad format for Apple's Mac OS X systems.
Just that it's darn near impossible to read/create from anywhere else ?

Similar with the PKG format (pax/bom), it works "OK" for the Mac 
installs
but I can't read/create the packages from any other platforms that I 
have.

> 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?

Yeah, I've done a few of those. Did some PKG resources for SDL,
but didn't bother too much with doing a DMG image background...

But I'll think I'll add the new SDL logo now, just as a little example.
(if I ever get the new PKG/DMG done that is, in my Copious Spare Time)

> 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 :)

If you are not going to support it / update it, then just delete them...
Same goes for the CWProjects, and even for the tiny little MPW 
makefiles ?

Having lived through most of this in the SpriteWorld project, I know 
what
kind of problems you get from having six different project files around.

(CodeWarrior Pro 5, CodeWarrior Pro 6, CodeWarrior 8,
  ProjectBuilder 2.0, Xcode 1.2 - 1.5, Xcode 2.0 - 2.1)

That's why I first started using MPW-GM, and later GNU Make instead. :-P
(for the Mac builds that is, it's a lot more common to use them on 
Linux)

The Makefiles have the advantage of being readable/editable by humans.
It's also *cheaper* than having to buy CodeWarrior or upgrade Mac OS X ?

Since SDL is part of my legacy builds, I'm juggling _all_ of the old 
ones.
(as I have the programs still installed on my Panther developer 
machine...)

When migrating to Tiger for next year or so, none of that will follow.
More used to Free Software now, so I will use that - unless I have to.


> 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.

I've built all of it here from "Classic", so it works (with a few 
tweaks)
Both the Classic builds (InterfaceLib), and the Carbon builds 
(CarbonLib)

 From a historical point of view, it's kinda sad to see the Mac platform 
go ?
Especially for a project like SDL that's been ported to some weird 
platforms.

--anders





More information about the SDL mailing list