Post by Anders F BjörklundI 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.
I agree that this would be the main reason to provide these scripts.
But my motivation by not providing it in the main package would be
basically to make people realize that this is not as portable as they
may think. For people starting a new development system, I would hate
for them to invest a lot on a build system they think is portable,
only to find later that foo-config doesn't work as well as they
thought. Now providing and sdl-config as a separate, unofficial
package, or maybe providing it so it is not automatically installed
and the user has to go through a setup process where they read
information where they get stern warnings about how this won't be
portable, I think would be acceptable. I'm not trying to prevent
people from doing what they wish to do as I like user choice, but I
want to make sure people fully know what they are getting into and not
encourage them to go down a bad path. (And there is also that nasty
issue of where to put the stuff and how not to clash with other
existing systems.)
Post by Anders F BjörklundYou 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)
Right, though as I said, I was hesitant to even do that, but the
questions kept coming up on the mailing list enough that it seemed I
needed to do something.
Post by Anders F BjörklundI 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 don't know all the Linux and other Unix distributions and don't know
what they provide. But I know it's impossible to guarantee consistency
which is the real problem. And when just one system doesn't support
it, it can really screw you over. For example, I was using SuSE 9.3
(or was it 9.2?) and the build process I had needed gnome-config. So
far, my determination is that at some point SuSE stopped providing the
gnome-config or it's one of those CD version vs DVD version issues
(though in the latter I don't think that's the case here since I have
all the other gnome-development stuff).
Post by Anders F BjörklundI 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"...
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.
I find that autotools aren't very "auto" which is unfortunate. Scons
has been recommended to me too, though I still haven't gotten around
to trying it. I can say I went with CMake because there is an actual
book you can buy on it so documentation is not so much of an issue,
and the fact that they have preliminary Xcode support which nobody
else does at the moment (though for OS X, I'm still using the Make
file generator at the moment or still use my handcrafted Xcode
projects). But I like CMake's module system because I've been able to
write detection modules much more easily than I could in autotools.
(I'm an autotool idiot.) So far the SDL modules work very well for me
on the platforms I've tried, and if something gets missed, you can
easily fix it as I did without needing to yell at that system's
package maintainer. For example, I can handle all of FreeBSD Port's
quirks without much effort. And there is no need to rely on things
like sdl-config.
Post by Anders F BjörklundA 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)
Yeah, this is a headache. I've been told they hope to stabilize the
situation. They were originally hoping that they could stabilize
things at Xcode 1.5/2.0 for Panther/Tiger, but the Intel
migration/Universal binary stuff forced some changes. They took that
as an opportunity to fix some other issues which broke compatibility
even more, but hopefully that means they won't break it down the line.
So hopefully things will eventually stabilize. But because of the
Intel migration, we do need to look ahead too.
Post by Anders F BjörklundThere 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.
Thinking about it some more, I definitely want to stay out of /usr and
any other Apple controlled area. I don't want to open that can of
worms. So, /usr/local would probably the best place, but it does
clash. And since we have mostly peaceful coexistence, we might be
surrendering that.
Post by Anders F BjörklundI 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...
Yes, that's why I've been thinking about moving it over to a .dmg
system. The downside is that you have 1 step for each copy. So copy
documentation, copy template projects, and (maybe?) copy sdl-config,
and copy libSDLmain.a. It's not exactly elegant. But it does simplify
a lot of things, and it removes our security burden which I think is
very desirable.
Post by Anders F BjörklundAFAIK, Apple fails to provide *any* uninstall or decent upgrade option
with their ancient Installer - unless you write it yourself with scripts
Right, that's what I was alluding too about uninstalling stuff.
Post by Anders F BjörklundThe .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.
Also: DarwinPorts and Fink does not use frameworks, just dylibs.
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 ?
Actually yes, the frameworks we distribute are intended to be shipped
in the .app bundle. We set the framework "install_path" variable to
@executable_path/../Frameworks which is an extremely important
subtlety in the frameworks we provide. These frameworks are really for
the developer, and shouldn't need to be something an end user has to
install or even think about. This is the primary reason we provide
Framework binaries and encourage their use, rather than recommending
building .dylibs or going to Fink or DarwinPorts (though we don't
prevent this if you want to...I think Ryan actually uses bundled
.dylibs for his own projects). Apple designed Frameworks so they could
be bundled easily without making the developer have to go to much
effort. I'm not sure if SDL developers have completely gotten that
message, but at least some have. Bob Ippolito's work is probably among
the best examples. He's ported/packaged Frozen Bubble, Pathological,
SolarWold, and Blobwars. I forgot who packaged GLTron, but they also
bundle the SDL.framework in the .app correctly. Basically these
binaries we provide are intended for developers to use, and then copy
into their .app bundle for deployment. (Maybe we should enhance the
Xcode templates so this is automatically done for you too.) The final
end user should never have to touch any of the stuff we provide, much
like a Windows end user should hopefully not need to download the
SDL.dll and it would be included with the app. If developers want to
use the traditional Unix techniques, that's fine too and I think we
have done a good job on the peaceful coexistence thing, but I think
our goals for the framework distribution is to make things very easy
for everybody, and to follow Apple guidelines so we are more resistant
to breakage. (For example, Apple has been telling people to move away
from CodeWarrior to Xcode for years, and now those who didn't are
paying for it.)
Post by Anders F BjörklundNo 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 ?
In reality, we probably still need the framework-only installation ?
(the sdl-config and devel-lite and libSDLmain.a can move to -devel)
My thinking has been rather than more packages and scripts, maybe we
should condense things down to a single package and make people
manually (drag) install since only developers should download this
stuff. At the most, I think we need to stick with 2 packages. I think
3 would be too confusing and more work.
Post by Anders F BjörklundSo 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)
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" ?
No, I strongly object to going back to the old system. The old system
was horribly complex (one of the reasons why our installers kept
breaking) and also totally broken on the multi-user paradigm. It also
makes things horribly confusing for Xcode and features like Zerolink
and Fix and Continue which will not work correctly depending how you
set things up. All of these were the reasons why I changed it. If the
application developer is worried about space and wants to strip the
headers themselves when they bundle the framework with their .app,
then that is perfectly fine. Though currently, I think the framework
download is about 250k (compressed) and this includes both the runtime
and headers. I personally don't think this is a big deal myself even
on a modem.
Post by Anders F BjörklundYou 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)
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)
Post by E. Wing2) 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.
If we go down this path, I'm starting to think perhaps the best thing
to do is make the user setup things themselves. This removes our
burden of figuring out where to put stuff and also removes any
concerns about where we install things to. If the person puts it into
/usr/local, they know they are responsible for any clashes. 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 :)
Post by Anders F BjörklundThere 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 ?
Actually, I tested the thing again. It looks like you might need -F
if installed to ~/Library/Frameworks. I don't remember this always
being the case. Maybe it is/was just Xcode that was smart enough to
figure this out or I'm just misremembering things. But regardless,
~/Library/Frameworks is the official and correct place we are supposed
to go to if not /Library/Frameworks (there is a
/Network/Library/Frameworks I don't talk about). I added documentation
about the -F flag in the devel-lite section, but Sam needs to replace
the current binary. I got it to him after he had announced the
release.
Thanks,
Eric