[SDL] Re: Problems with the Mac projects

Anders F Björklund afb at algonet.se
Tue Sep 6 14:05:25 PDT 2005


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

> 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





More information about the SDL mailing list