Problems with the Mac projects

SDL Development
1

I tried the various Xcode projects in SDL 1.2.9,
and they each seem to be having some issues…

a) PBProjects.tar.gz (for Mac OS X 10.2, PB 2.1)

This one looked out of date, and had been "upgraded"
by Xcode it seemed. Downgrading it again, and adding
the missing “SDL_coreaudio.c” seems to have worked ?

b) Xcode.tar.gz (for Mac OS X 10.3, Xcode 1.5)

This one was mostly cosmetic, looked like a real
quick-n-dirty upgrade from the old ProjectBuilder…
All the targets were still named " (Upgraded)", and
the non-native targets were still left in the project ?
The bundle suffix should be changed too, to: SDL.xcode

c) Xcode21.tar.gz (for Mac OS X 10.4, Xcode 2.1)

This project, like the others before it, uses the
aggressive “-O3” optimization. This setting, and in
fact anything above “-O”, seems to crash fat builds…
(i.e. Apple’s gcc4 compiler segfaulted when building)
When building for PowerPC/Intel, it had to be eased up.
Project is now named SDL.xcodeproj, new format (again).

Some other notes (same for all three versions)
They were mostly being “documented”, but anyway.

  • Why does the “build” install the framework ?
    (that should be done in the “install” style)

  • Why is the default build style “Development” ?
    (wouldn’t “Deployment” be a better default)

  • Wouldn’t it be easier to have the xcode plist dirs in
    the CVS, instead of the three compressed tarballs ?

  • Some of the pkg-support still says “SDL 1.2.8”, and
    also uses a bunch of hacks (like the “package” script)

Might as well switch to using Apple’s PackageMaker ?
(there’s one for each major Xcode version, as usual)

I’m assuming that you want to continue all three
development platforms and now five deployment ones…
(counting Mac OS X86 10.4u/Universal Binary as one)

Otherwise, ProjectBuilder and Mac OS X 10.1 could
be scrapped now as they are getting pretty obsolete.
(bringing it down to two dev. and four dep. platforms)

–anders

PS.
But the new patch for SDL 1.2.9 seems to be working fine,
so I’ll post that in the weekend. Even built as “fat”…
(after upgrading gnu libtool to anything 1.5.2, or later)

2

I tried the various Xcode projects in SDL 1.2.9,
and they each seem to be having some issues…

a) PBProjects.tar.gz (for Mac OS X 10.2, PB 2.1)

This one looked out of date, and had been "upgraded"
by Xcode it seemed. Downgrading it again, and adding
the missing “SDL_coreaudio.c” seems to have worked ?

This one has basically been abandoned.

b) Xcode.tar.gz (for Mac OS X 10.3, Xcode 1.5)

This one was mostly cosmetic, looked like a real
quick-n-dirty upgrade from the old ProjectBuilder…
All the targets were still named " (Upgraded)", and
the non-native targets were still left in the project ?
The bundle suffix should be changed too, to: SDL.xcode

Yes, it is was a quick and dirty upgrade by me to get things just
working. I think this was done in the era when everything just broke
and the priority was to get something working. The .pbproj extension
is what Xcode left during the upgrade (it didn’t change it to .xcode)
rather than risk breaking anything else.

This project will probably be abandoned too. I have spoken to both
Ryan and Sam about keeping these old projects up to date, and I think
everybody feels that it is a waste of our time. As long as we can
provide a prebuilt framework and people can build SDL through other
methods, we don’t feel an urgency to maintain these projects. (And as
you know, it’s very hard to maintain since Xcode keeps breaking
compatibility.) Both of these projects will probably be "officially"
deprecated in the near future, but they are effectively dead. But they
are currently left around in case somebody might need them. With some
persistence, they can be fixed up as you have done.

c) Xcode21.tar.gz (for Mac OS X 10.4, Xcode 2.1)

This project, like the others before it, uses the
aggressive “-O3” optimization. This setting, and in
fact anything above “-O”, seems to crash fat builds…
(i.e. Apple’s gcc4 compiler segfaulted when building)
When building for PowerPC/Intel, it had to be eased up.
Project is now named SDL.xcodeproj, new format (again).

I was not aware of this. I don’t recall having this problem at WWDC,
but I only had a few days to play with it. However, I am aware of a
set of bugs when dealing with universal binaries in general, some of
which will make universal development extremely difficult (if not
impossible). So I’ve been holding off releasing a universal build of
the framework until Apple fixes these problems (hopefully Xcode 2.2).
I’m expecting the first Intel Macs are still awhile away, so I’m
hoping we can put off the universal binary until the next SDL release.

Anyway, I strongly recommend you file this crashing bug with Apple’s
Radar so they can fix the problem. (My personal experience with these
kinds of issues is that Apple actually does fix them if you report
them with detailed bug reports.)

Some other notes (same for all three versions)
They were mostly being “documented”, but anyway.

  • Why does the “build” install the framework ?
    (that should be done in the “install” style)

Does it actually install the framework? This is legacy stuff that was
in the projects when I started playing with them. I saw that box, but
I never actually have seen the system “install” the framework. I
assumed it was disabled by something else.

  • Why is the default build style “Development” ?
    (wouldn’t “Deployment” be a better default)

I think this is controlled by the user preferences. In each Xcode
project, a preferences file is created for every user which contains
their personal settings. (We strip these files before checking in.) So
when a new user opens the project, they get their own settings and I
think it just defaults to Development. One of the Apple engineers told
me a way to create a default preferences for all people, but I didn’t
feel it was worth the effort.

  • Wouldn’t it be easier to have the xcode plist dirs in
    the CVS, instead of the three compressed tarballs ?
  • Some of the pkg-support still says “SDL 1.2.8”, and
    also uses a bunch of hacks (like the “package” script)

I’m trying to find ways to simplify the entire process. You might
notice that with the Xcode 2.1 stuff, I’m trying to remove some of the
extra files and directories. I’m not sure how safe it is to share the
stuff between Xcode projects though since compatibility has been a
problem. But pretty open to ideas here.

Might as well switch to using Apple’s PackageMaker ?
(there’s one for each major Xcode version, as usual)

The package script has a long ugly history that dates back quite a
ways. I actually don’t even know the full story. But I think Apple’s
PackageMaker was introduced in Panther which caused problems for
Jaguar and older. (I also have trouble finding documentation on
command line arguments for PackageMaker.) In addition, Apple used to
have a command line package script included with the OS which got
removed in either Jaguar or Panther. And I think in one of those, they
changed something in the OS so the package script actually broke
because a command it dependent on changed. Anyway, this completely
broke the packaging system for awhile. Somebody (I’m not sure who) got
this package script running and placed it directly in the CVS. So it
works for now, and works everywhere as far as I know.

But because of this problem, and the authentication issues with
package installers, I’ve been opting for a .dmg based system which you
start seeing in the Xcode 2.1 project.

I’m assuming that you want to continue all three
development platforms and now five deployment ones…
(counting Mac OS X86 10.4u/Universal Binary as one)

Actually, I think the feeling is to eventually drop the projects
before Tiger as long as we can supply a binary framework that works
for people so they need not build it themselves.

Otherwise, ProjectBuilder and Mac OS X 10.1 could
be scrapped now as they are getting pretty obsolete.
(bringing it down to two dev. and four dep. platforms)

Good idea :slight_smile:

–anders

PS.
But the new patch for SDL 1.2.9 seems to be working fine,
so I’ll post that in the weekend. Even built as “fat”…
(after upgrading gnu libtool to anything 1.5.2, or later)

Thanks,
Eric> Date: Fri, 2 Sep 2005 13:17:36 +0200

From: Anders F Bj?rklund

3

E. Wing wrote:

This project will probably be abandoned too. I have spoken to both
Ryan and Sam about keeping these old projects up to date, and I think
everybody feels that it is a waste of our time. As long as we can
provide a prebuilt framework and people can build SDL through other
methods, we don’t feel an urgency to maintain these projects. (And as
you know, it’s very hard to maintain since Xcode keeps breaking
compatibility.) Both of these projects will probably be "officially"
deprecated in the near future, but they are effectively dead. But they
are currently left around in case somebody might need them. With some
persistence, they can be fixed up as you have done.

I’m cleaning out a few other murky places in my attic,
so I will probably do one final release for all of them.
Even including CodeWarrior Pro 6, and Pro 5, and MPW (!),
as detailed in that other Mac email I posted to the list…

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)

I was not aware of this. I don’t recall having this problem at WWDC,
but I only had a few days to play with it. However, I am aware of a
set of bugs when dealing with universal binaries in general, some of
which will make universal development extremely difficult (if not
impossible). So I’ve been holding off releasing a universal build of
the framework until Apple fixes these problems (hopefully Xcode 2.2).
I’m expecting the first Intel Macs are still awhile away, so I’m
hoping we can put off the universal binary until the next SDL release.

I’m not sure that it crashes an actual MacIntel, I only know that it
does crash Mac OS X 10.4 (PPC) when building a fat/universal binary ?
I also know that the glibtool on Tiger is too old to rebuild properly…

With all the new fun bugs, feels like I’m back on Mac OS X 10.0 again.

Anyway, I strongly recommend you file this crashing bug with Apple’s
Radar so they can fix the problem. (My personal experience with these
kinds of issues is that Apple actually does fix them if you report
them with detailed bug reports.)

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”.
:frowning:

Does it actually install the framework? This is legacy stuff that was
in the projects when I started playing with them. I saw that box, but
I never actually have seen the system “install” the framework. I
assumed it was disabled by something else.

Well, it was in the old projects - so it’s probably just old leftovers.

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 think this is controlled by the user preferences. In each Xcode
project, a preferences file is created for every user which contains
their personal settings. (We strip these files before checking in.) So
when a new user opens the project, they get their own settings and I
think it just defaults to Development. One of the Apple engineers told
me a way to create a default preferences for all people, but I didn’t
feel it was worth the effort.

It most likely isn’t. “xcodebuild -buildstyle Deployment” will do it.

I’m trying to find ways to simplify the entire process. You might
notice that with the Xcode 2.1 stuff, I’m trying to remove some of the
extra files and directories. I’m not sure how safe it is to share the
stuff between Xcode projects though since compatibility has been a
problem. But pretty open to ideas here.

I do have a few such ideas, will see how they work out in practice…

There’s a simple solution struggling to get out, in here somewhere.

The package script has a long ugly history that dates back quite a
ways. I actually don’t even know the full story. But I think Apple’s
PackageMaker was introduced in Panther which caused problems for
Jaguar and older. (I also have trouble finding documentation on
command line arguments for PackageMaker.) In addition, Apple used to
have a command line package script included with the OS which got
removed in either Jaguar or Panther. And I think in one of those, they
changed something in the OS so the package script actually broke
because a command it dependent on changed. Anyway, this completely
broke the packaging system for awhile. Somebody (I’m not sure who) got
this package script running and placed it directly in the CVS. So it
works for now, and works everywhere as far as I know.

It was Jaguar that had the broken packagemaker (as it didn’t work for
Puma)
But it doesn’t matter, it all breaks and changes formats (along with
Xcode)
The BOM format is proprietary anyway, so it’s hard to make a complete
tool.

Apple’s “tool” is located at the convenient path (use -help for the
parameters)

/Developer/Applications/Utilities/PackageMaker.app/Contents/MacOS/
PackageMaker
But it still requires you to generate the long info/desc XML files
yourself…

I’ve written a GPL script to convert RPM to PKG myself, it’s called
"rpm2pkg":
http://cvs.sourceforge.net/viewcvs.py/rpm4darwin/rpm2pkg/rpm2pkg.pl?
view=auto
Maybe it could be built on, to provide more “general” build/packaging
scripts.

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

But because of this problem, and the authentication issues with
package installers, I’ve been opting for a .dmg based system which you
start seeing in the Xcode 2.1 project.

Might as well move to .tar.gz or .zip format then ? (lose the .dmg too)

I’m using ZIP archives myself, in a move away from the older StuffIt…
Just wished the new “__MACOSX” folder was documented/supported better.
(I know it’s just an AppleDouble version of the Mac stuff, but anyway)

Actually, I think the feeling is to eventually drop the projects
before Tiger as long as we can supply a binary framework that works
for people so they need not build it themselves.

In theory, Tiger should be able to build for all of: Mac OS X 10.1 -
10.4

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

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)

–anders

4

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

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”.
:frowning:

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

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.

Thanks,
Eric> Date: Tue, 6 Sep 2005 23:05:25 +0200

From: Anders F Bj?rklund

5

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

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

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

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. :stuck_out_tongue:
(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

6

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 still build and maintain that, for fun. As long as my iBook keeps
chugging along, I’ll still release binaries for it. :slight_smile:

-Sam Lantinga, Software Engineer, Blizzard Entertainment