[SDL] Re: SDL 1.2.9 PRERELEASE (Mac OS X)

[Anders F Björklund]

E. Wing wrote:

> So first, while I am not totally opposed to the idea of including a
> libSDLmain.a and sdl-config in the framework distribution, I am
> resistant to the idea, at least for the official binaries. If you
> check the .dmg prerelease documentation in the "devel-lite" section,
> you'll see a brief explanation about it. You'll also see we now try to
> help new people and those who don't want to deal with the Xcode
> projects by providing the gcc command line you will need.

I saw that with the SDL 1.2.9 release. The sdl-config and libSDLmain.a
actually contained the same things that the "devel-lite" and docs did,
just packaged up as a script and as a pre-compiled library instead.

The *main* reason for providing them is so that Makefiles from other
platforms will work "right out the box". Most Mac users will probably
be using Xcode anyway, so the templates should be plenty for them.

> The reason I highlight in the documentation is that it is my
> understanding that there are actually multiple versions of SDLmain
> which give you different features. Because of this, I feel it is not
> entirely correct to build a libSDLmain.a around just one version. I'm
> somewhat unsatisfied with actually including one version of the
> SDLmain files, but hopefully, this plus the documentation will at
> least make people aware of the issue now.

You are right in that there are several versions, but I think we
should still ship the "minimal" (non-nib Quartz) version of it...
(the SDLmain.m used there was the same one as in "devel-lite", BTW)

> But there are some other reasons I'm not enthusiastic about the idea
> of the sdl-config script. Here are a few. First, foo-config is
> typically used by autoconf systems. There is a presumption that this
> is portable, which tends not to be the case. I know Ryan is getting a
> headache from dealing with autoconf for SDL and his projects, and
> would remove it entirely if it wasn't expected that there be at least
> a minimal autoconf system.
> But putting aside autoconf specific issues, people might start
> assuming sdl-config is always available and is always found by the
> same name, which is is not. They write their entire build system
> around this, and when they try to move to another computer, they run
> into problems. Obviously, you know that some systems don't even
> provide the script (like our prior OS X SDL frameworks). But another
> example is that FreeBSD ports doesn't name their script "sdl-config",
> but "sdl11-config" so the build systems typically fail to find it.
> It's a real pain.

I haven't used FreeBSD (no idea why they did such a renaming?) but I do
know that the Linux and MinGW versions are happily using the sdl-config.

I gave up on using autocrud for my own project and just used GNU Make,
since it had a very hard time even locating just SDL and OpenGL for me ?

While I would prefer that there was a "canon" way for autoconf to find
libsdl and opengl, using sdl-config and SDL_opengl.h is working "OK"...

> So rather than encouraging people to entrench
> themselves in a system that is most likely going to give them
> portability headaches, I think it might be better for people to either
> understand the build system for their platform (which I tried to start
> documenting in the .dmg) or seek out and use better systems. Might I
> suggest CMake? I recently submitted a whole bunch of FindPackage
> scripts SDL and satellites, OpenAL, PhysFS, and SDL_sound which are
> now in their CVS and will likely be included in the next release. The
> nice thing about CMake is that it builds native projects for a handful
> of build systems like Visual Studio (Xcode is still a bit
> experimental), so you aren't just limited to makefiles. It's also a
> much smarter system as it can look for libraries that have different
> paths or names on different systems. Because of all this, I find it
> way more portable. (By the way, if somebody ever puts in native OS X
> framework support for CMake, I'll probably start looking at making a
> CMake build system for SDL so we don't have to keep maintaining
> separate native project build systems.)

Seems like every year, someone rebuilds "make"... I've already been 
suggested to use scons and prebuild and a few others that I forgot.
And I used to use Mac OS 9, which didn't even *have* such a system.

While you are probably right, and while I "should" switch over from
using Make to something new and from CVS to Subversion (or something)
- I still think it should work with the traditional systems as well ?

A special headache with Xcode is that there is one version of it
for each version of Mac OS X (each with their own project format)

> Another problem which you touched on is where do we put the thing? 
> I'm very nervous and hesitant to put anything in Apple controlled
> directories like /usr/bin. Apple has repeatedly warned developers not
> to do this, particularly with the /System directory. I'm less sure
> about the rules for /usr, but I suspect it's the same so I want to
> keep out of it. I think /usr/local would be the place to put it if we
> went down this path, but as you pointed out, it will clash with people
> would also built their SDL themselves. We're in kind of a nice state
> now, where people can use multiple packaging systems (the frameworks,
> Fink, DarwinPorts, build yourself), and still (mostly) peacefully
> coexist. It would be a shame to give that up. My instinct at this
> point would be to force the user to explicitly decide if they want to
> use an sdl-config, and then decide where to put it, rather than having
> an installer muck with things on their system behind the user's back.

There wouldn't be a problem with placing it in /usr/bin, since
/sw/bin (Fink) and /opt/local/bin (DarwinPorts) would be prior
to it in the PATH - but they _can_ place it somewhere else and
play with the "prefix" parameter and friends. (-I and -L and -F)

I generally feel like /usr/local/bin is a better "match" for
/Library/Frameworks, this was an exception due to the clash.

Also: DarwinPorts and Fink does not use frameworks, just dylibs.

> Which brings me to the topic of installers.
> I'm also trying to move us away from the Installer package system and
> to something like a .dmg system. I haven't done this yet for the
> dev-package, but it might be coming. The main problem is security.

I actually unpacked the dev-package without installing it,
and found that it *really* didn't need an installer anyway ?

Especially since it didn't contain any headers or libraries,
but just the html documentation files and template projects...

> Because of all the problems people are having with spyware and viruses
> (usually on Windows), people have become (rightly) scared to install
> anything. I think a lot of people's experience with uninstallers is
> that they don't work either. While OS X currently experiences fewer of
> these problems, I don't want to contribute to the overall problem.
> Apple still fails to provide a good way to uninstall stuff, and our
> installer for SDL is actually too complicated in my opinion. People on
> this might recall that our OS X installer was broken on several
> occasions on new releases of SDL and friends which has been one of the
> primary reasons for these changes. And I believe our installer needs
> Admin access which makes me extremely nervous especially since our
> scripts keep breaking which do stuff like removie files and change
> permissions. I think we need a better non-admin alternative too as
> some people don't have admin access, or are not willing to surrender
> it for security reasons.

AFAIK, Apple fails to provide *any* uninstall or decent upgrade option
with their ancient Installer - unless you write it yourself with scripts

It's also a proprietary format and doesn't offer any build tools either,
so as a package manager goes it is fairly limited (as I'm used to RPM)


The .pkg installer I had in mind was for the budding SDL would-be 
developer, since the end-user should not have to install it IMHO.

No scripts or funny business, just files (with correct file permissions)
- /Library/Frameworks/SDL.framework ("SDL.framework")
- /usr/bin/sdl-config ("bin")
- /usr/lib/libSDLmain.a ("lib")

Then again, without any scripts it's also hard to make it relocatable...
(which was a simple boolean, when it just had the SDL.framework before)
Perhaps three directories and one InstallMe.command would work better ?


Just as Apple's guidelines says that you have to ship 500K of headers
with the framework, it also says that you *should* be including the
SDL.framework in the Frameworks directory of your Game.app bundle ?

So normal SDL-using Mac programs should be stand-alone without having
to direct the end-user to any package for completing the installation ?
(it does of course add some 300K overhead to *each* application, but)

In reality, we probably still need the framework-only installation ?
(the sdl-config and devel-lite and libSDLmain.a can move to -devel)

Maybe we should even go back to the old SDL package, which had one
framework without the headers (saves 300 KB on the zipped download)
and one "full" developer framework with the all the headers and
symbols and support scripts and support libraries like "main" ?


> Anyway, I've started migrating everything except the dev-package
> because it is the only thing that hasn't broken recently, and I do
> like the one step install. A dev-dmg might require 2 or 3 copies since
> there are unrelated files that have to be placed in file system. But
> if/when it does break, I'll probably convert it over. But this is also
> why I'm hesitant to add new things to our current installer.

You can move the remaining files out and provide a "install.sh" or so ?
(for moving the templates folder into the correct directory, and so on)

BTW; If you rename the script with .command, it becomes double-clickable
(can just use "sudo" inside it, if it needs to have "admin" priviledges)

> Anyway, that's my opinion on the issue for the official binaries. As
> an unofficial, separate package (or just a separate download for just
> the script with some notes), I don't really see it as a problem. But
> if Sam or Ryan say they want it in the official package, I'll see
> about adding it. But there are a few things I don't know how to
> answer:
> 1) Where does the sdl-config go (/usr/bin, /usr/local/bin, in the
> framework itself?)
> (Or do we even attempt to place it in the file system, and instead
> make the user place it instead?)

The idea was to place it in /usr/bin if user has the privledges,
or else just provide a "bin" directory next to the SDL.framework.
(similar with a "lib" directory for containing any libSDLmain.a)

> 2) If we do automatically place the file, do we automatically write
> the correct the locations for the sdl-config script. The installer no
> longer controls where the SDL.framework gets placed as that is now a
> drag-and-drop operation through the .dmg. We would need to write some
> detection routines for where the framework is located.

There are only two valid default locations: /Library/Frameworks
and ~/Library/Frameworks. So the user should only need to provide
a -F path if they have installed it in some non-standard location ?

But I do think that it would be nice if the sdl-config matched,
but haven't written such an "improved" installer package just yet...

> By the way, your --libs  line in your sdl-config script includes
> Carbon which isn't necessary as far as I know, and OpenGL only needs
> to be linked if the application actually uses OpenGL. While this
> probably won't cause any problems, I've taken my share of newbie
> questions who don't understand what linking is and what things
> actually need to be linked and start adopting bad behaviors based upon
> information that tells them to link against stuff they really don't
> need. By the limited nature of the sdl-config structure, you might not
> be able to remove the OpenGL part, but I think you should remove the
> Carbon line.

Sorry, I took that script right off my own files - that do have support
both for Cocoa ("Quartz") and for Carbon ("toolbox") video drivers...

I think the OpenGL support was there due to the missing SDL_loadobject
support, but I will compile it with a static libcompat instead I think.

Also, in the old patch it preferred a) X11 and b) Carbon which is wrong.
If all three are available, it should use the Quartz driver (move it up)


Either way, it won't be in SDL 1.2.9 and we can tweak it further ahead.
I will do a test install packages, and see how it works out in practice?

--anders