[SDL] Re: Problems with the Mac projects
ewmailing at gmail.com
Tue Sep 6 12:59:17 PDT 2005
> Date: Fri, 2 Sep 2005 13:17:36 +0200
> From: Anders F Bj?rklund
> 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 :)
> 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)
More information about the SDL