E. Wing ewmailing at gmail.com
Tue Sep 6 12:16:52 PDT 2005

> Date: Wed, 31 Aug 2005 10:16:50 -0600
> From: Tyler Montbriand 
> Subject: Re: [SDL] Re: SDL 1.2.9 PRERELEASE (Mac OS X)

> Isn't the *reason* it's not portable to osx because it's not installed?
> Refusing to install it because it's not portable is a self-fulfilling
> prophecy.

Yes, this is one of the reasons and it is somewhat self-fulfilling,
but it is also legacy thing. It's been like this for years (long
before my involvement) so it's been established that it's not
portable. Providing it now doesn't help on those systems with older
(heck, current) SDL installations, or help people on other systems
where sdl-config is not available either (which is the bigger
problem). For example, regardless of what we decide for OS X, it will
not fix FreeBSD ports. I also found David Olofson's comments about
cross-compiling particularly enlightening.Then there is this little OS
called Windows.

> I've used xcode and makefiles under osx, and when it comes down to it, OSX is
> UNIX, and Xcode uses the same compiler facilities as make.  The buildflags
> are a little odd, but that's what sdl-config is there to help you with.

This isn't a Makefile vs Xcode issue. You can use either. You can use
Makefiles and command line gcc perfectly well without sdl-config. This
is specifically about sdl-config which is a separate issue.  As I've
pointed out, sdl-config is an absolute mess if you depend on it for
portability. Cutting out the middle-man entirely and telling people
what the flags are as I've tried to start doing in the documentation I
think is a generally safer approach rather than getting people hooked
on sdl-config like a drug.

> > (And there is also that nasty issue of where to put the stuff and how not to
> > clash with other existing systems.)
> Um, /usr/local/bin?
No, we've already said that it will clobber the sdl-config created by
building SDL yourself through the autoconf system. Both Anders and I
have pointed this out.

> It's impossible to provide consistency when installations are inconsistent,
> yes.  How is this a point in favor of being inconsistent?
As I have mentioned, there are other build systems out there that are
more resilient to these kinds of differences. sdl-config is not one of
them though.

> ldflags were: -framework SDL -framework Cocoa -lobjc /path/to/libSDLmain.a

FYI, the -lobjc isn't necessary because it is automatically brought in
by -framework Cocoa as far as I know.

> The problem is, OSX comes with the GNU build tools, not cmake.  And lots of
> things *do* rely on sdl-config.  Telling people to not use it won't stop the
> rest of the world, and it really *is* quite useful.

As I said, I'm not opposed to letting people use an sdl-config script
if they choose. As you should already know, Anders is supplying one

> Unlike lots of other UNIX systems, /usr/local/bin is in the default executable
> path under OSX.  Put it there and it should work.  

No, it is not. Every new install or new account of OS X I have never
includes /usr/local/bin in the path. In fact, I currently have an
account open in front of me that doesn't have /usr/local/bin in the

> A UNIX system without
> sdl-config isn't exactly a "peaceful coexistence" from my POV;  

Peaceful coexistence was about people having Fink, Darwin Ports, the
Frameworks, and their own autoconf built versions of SDL installed
simultaneously. If I break that, I will hear from an entirely
different group of angry people.

> the developer
> package is only directly useful if you're using xcode.  What if people hate
> xcode?
And again, the SDL packages have changed if you haven't noticed. The
main package now comes with files and documentation to help people who
just want to do command line builds. The developer package currently
has both documentation (for everybody), and Xcode templates. The
developer package is now actually optional as the basics can now be
done through the main .dmg.

I understand that people may not want to use Xcode. This new package
separation was designed to help those people. And since the security
issue should trump all, my intention is to change the developer
packages (in the process of being renamed devel-extras) into a dmg
instead of an installer so people can manually elect what to install
(or not install). This way people can access the documentation without
having to install the Xcode templates.

> It took a bit of hunting on my part to figure out how these things should be
> organized, and modifications to SDLMain.m to get it to use framework
> resources properly.  I think this could use some better developer
> documentation.
Yes, the documentation is still weak. That's something I've been
trying to work on (hence the new "devel-lite" section). But this is a
volunteer effort for me. I have a lot of other responsibilities so
it's been slow coming. I'm also not the original creator of the
current packaging system, so maintaining and changing the current
system requires additional effort on my part too. That's why
simplifying things and removing scripts is my preference. Whoever
eventually succeeds me will have to deal with whatever I leave behind.
And it is extremely difficult to change things because no matter what
you do, you will make somebody mad. The simpler the system, the easier
that will be for them. The SDL FAQ for OS X needs an update too which
is also on my radar.

> The UNIX tools and the Apple Way(tm) are not fundamentally incompatible.
> I ported the latest blobwars, 1.05, to OSX and cobbled together an OSX ".app"
> without needing to touch xcode with a 10 foot pole.  I don't think we need to
> worry about the GNU tools going away any time soon either.  Xcode can't live
> without them afaik.
I never said they were. In fact, nowhere have I said, "Thou shall use
Xcode". As I've pointed out several times, there is now documentation
that explains what the gcc build flags are and how to build directly
on the command line. In fact, we now give more documentation on the
command line builds than we do with the Xcode projects :). The
discussion about frameworks/dylibs is completely orthogonal to the
issue of Xcode/gcc. And in all cases, I think we have done a good job
to support user choice, because as it stands right now, you can do it
any of these ways you choose (commandline/Makefiles, Xcode, Fink,
DarwinPorts, build youself, Frameworks).

> Clashes like what?  /usr/local/bin is in the normal executable path, and
> nothing else is going to install sdl-config...

Clashes with building SDL yourself via autoconf. And no,
/usr/local/bin not in the normal executable path. And no, that's not
true either which has been already pointed out.

> > And if they put it into /usr, they know they are doing so against Apple's
> > advisement. It will also force people to read the documentation where
> > we should explain all the hazards of using this stuff. And if the user
> > screws up their system, it's not our fault :)

> What's the point of providing anything then?  Just tell them to eff off and
> compile it themselves.

I'm not sure what you were getting at here but this only pertains to
the idea of installing sdl-config to /usr/bin and libSDLmain.a to
/usr/lib and how we shouldn't put anything in Apple system (reserved)
locations. Both Anders and I have considered /usr/local as a possible
candidate, but there is the clobber issue (and I suppose the search
path issue).


More information about the SDL mailing list