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