Discussion:
SDL 1.2.9 PRERELEASE
Sam Lantinga
2005-08-21 08:53:15 UTC
Permalink
The SDL 1.2.9 PRERELEASE is available!
Please try it out and let us know if there are any bugs or build issues.

Source:
http://www.libsdl.org/cvs/SDL-1.2.9.tar.gz
http://www.libsdl.org/cvs/SDL-1.2.9.zip
http://www.libsdl.org/cvs/SDL-1.2.9-1.src.rpm

Linux X86 binaries:
http://www.libsdl.org/cvs/SDL-1.2.9-1.i386.rpm
http://www.libsdl.org/cvs/SDL-devel-1.2.9-1.i386.rpm

Windows X86 binaries (built with VC++ 2005 Express Edition Beta 2):
http://www.libsdl.org/cvs/SDL.dll
http://www.libsdl.org/cvs/SDL-devel-1.2.9-VC2005.zip

MacOS X PPC binaries:
http://www.libsdl.org/cvs/SDL-1.2.9.pkg.tar.gz
http://www.libsdl.org/cvs/SDL-devel-1.2.9.pkg.tar.gz

Changes since 1.2.8:
* Numerous improvements to the Atari port (thanks Patrice!)
* SIGTERM and SIGINT handlers are reset when SDL shuts down
* Added support for Visual C++ 2005 (Express Beta 2) to VisualC.zip
* Fixed crash trying to allocate hardware surfaces on MacOS X (thanks Ryan!)
* Fixed SDL.DLL so it works on Windows 95 again
* Dropping a document onto an SDL app passes it as a command line parameter in MacOS X (thanks Ryan!)
* Fixed short read problem with SDL_RWFromMem() (thanks Antonio!)
* Added support for SDL_VIDEO_X11_NODIRECTCOLOR on OpenGL visuals
* Altivec optimized blitters (thanks Bob!)
* YUV mmx code should work with gcc 2.x and 3.x (thanks Stephane!)
* Fixed hang on shutdown using framebuffer console on ia64 (thanks Jesse!)
* Improved RISC OS support (thanks Peter and Alan!)
* Added support for direct color 8-bpp surfaces
* Fixed gcc parse errors in SDL_audio.h on Windows
* Fixed potential crash in multi-threaded timers
* Added support for Tru64 UNIX 4.X (thanks Hayashi!)
* SDL_OPENGLBLIT has been renamed SDL_OPENGLBLIT_OBSOLETE

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Gerry JJ
2005-08-21 12:50:35 UTC
Permalink
Post by Sam Lantinga
The SDL 1.2.9 PRERELEASE is available!
Please try it out and let us know if there are any bugs or build issues.
Build fails here with gcc 3.2.2. It works fine with gcc 3.3.5.

Here's the error I get with 3.2.2. It happens when compiling
src/video/SDL_yuv_mmx.c (this is with default configure options):

../../../../Source/SDL-1.2.9/src/video/SDL_yuv_mmx.c: In function
`ColorRGBDitherYV12MMX1X':
../../../../Source/SDL-1.2.9/src/video/SDL_yuv_mmx.c:113: can't find a
register in class `GENERAL_REGS' while reloading `asm'
../../../../Source/SDL-1.2.9/src/video/SDL_yuv_mmx.c: At top level:
../../../../Source/SDL-1.2.9/src/video/SDL_yuv_mmx.c:59: warning:
`MMX_Ugrn555' defined but not used
../../../../Source/SDL-1.2.9/src/video/SDL_yuv_mmx.c:60: warning:
`MMX_Vgrn555' defined but not used
../../../../Source/SDL-1.2.9/src/video/SDL_yuv_mmx.c:64: warning:
`MMX_red555' defined but not used
../../../../Source/SDL-1.2.9/src/video/SDL_yuv_mmx.c:66: warning:
`MMX_grn555' defined but not used
../../../../Source/SDL-1.2.9/src/video/SDL_yuv_mmx.c:68: warning:
`MMX_blu5x5' defined but not used
make[3]: *** [SDL_yuv_mmx.lo] Error 1
make[3]: Leaving directory `/home/trick/Build/SDL-1.2.9/src/video'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/trick/Build/SDL-1.2.9/src/video'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/trick/Build/SDL-1.2.9/src'
make: *** [all-recursive] Error 1

- Gerry
Patrick McFarland
2005-08-22 00:19:43 UTC
Permalink
Post by Gerry JJ
Post by Sam Lantinga
The SDL 1.2.9 PRERELEASE is available!
Please try it out and let us know if there are any bugs or build issues.
Build fails here with gcc 3.2.2. It works fine with gcc 3.3.5.
You shouldn't be using such an ancient compiler.
--
Patrick "Diablo-D3" McFarland || ***@downeast.net
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989
Stephane Marchesin
2005-08-22 20:59:42 UTC
Permalink
Post by Gerry JJ
Post by Sam Lantinga
The SDL 1.2.9 PRERELEASE is available!
Please try it out and let us know if there are any bugs or build issues.
Build fails here with gcc 3.2.2. It works fine with gcc 3.3.5.
Here's the error I get with 3.2.2. It happens when compiling
../../../../Source/SDL-1.2.9/src/video/SDL_yuv_mmx.c: In function
../../../../Source/SDL-1.2.9/src/video/SDL_yuv_mmx.c:113: can't find a
register in class `GENERAL_REGS' while reloading `asm'
`MMX_Ugrn555' defined but not used
`MMX_Vgrn555' defined but not used
`MMX_red555' defined but not used
`MMX_grn555' defined but not used
`MMX_blu5x5' defined but not used
make[3]: *** [SDL_yuv_mmx.lo] Error 1
make[3]: Leaving directory `/home/trick/Build/SDL-1.2.9/src/video'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/trick/Build/SDL-1.2.9/src/video'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/trick/Build/SDL-1.2.9/src'
make: *** [all-recursive] Error 1
What does gcc -v says ?

Stephane
Gerry JJ
2005-08-22 22:04:49 UTC
Permalink
Post by Stephane Marchesin
What does gcc -v says ?
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-pc-linux-gnu/3.2.2/specs
Configured with: ../../Source/gcc-3.2.2/configure i386-pc-linux-gnu
--prefix=/usr --enable-languages=c,c++
Thread model: posix
gcc version 3.2.2

Could it be because the compiler was compiled for i386-pc-linux-gnu ?
That shouldn't have any effect on the code-generation abilities of the
resulting compiler, should it ? In any case, it worked fine with
earlier SDL releases.

(And yes, I know this gcc version is pretty old now, but I can't/won't
upgrade on that system at the moment for reasons I won't get into here)

- Gerry
Stephane Marchesin
2005-08-23 00:16:02 UTC
Permalink
Post by Gerry JJ
Post by Stephane Marchesin
What does gcc -v says ?
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-pc-linux-gnu/3.2.2/specs
Configured with: ../../Source/gcc-3.2.2/configure i386-pc-linux-gnu
--prefix=/usr --enable-languages=c,c++
Thread model: posix
gcc version 3.2.2
Could it be because the compiler was compiled for i386-pc-linux-gnu ?
Nope, i386-pc-linux-gnu is the right target.

Actually, I asked this because it works here on :
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/specs
Configured with: ../configure --prefix=/usr --libdir=/usr/lib
--with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-shared --enable-threads=posix --disable-checking
--enable-long-long --enable-__cxa_atexit
--enable-languages=c,c++,ada,f77,objc,java
--host=i586-mandrake-linux-gnu --with-system-zlib
Thread model: posix
gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk)

Frankly, I suspect you have a bug in your gcc version (it looks to me
like it has been pulled from cvs, where they usually break such things),
because there are enough x86 registers, so there is no reason for this
error. What distro ships this gcc ?
Post by Gerry JJ
That shouldn't have any effect on the code-generation abilities of the
resulting compiler, should it ? In any case, it worked fine with
earlier SDL releases.
(And yes, I know this gcc version is pretty old now, but I can't/won't
upgrade on that system at the moment for reasons I won't get into here)
No worries, we support down to gcc 2.95.

Stephane
Gerry JJ
2005-08-23 12:34:39 UTC
Permalink
Post by Stephane Marchesin
Frankly, I suspect you have a bug in your gcc version (it looks to me
like it has been pulled from cvs, where they usually break such things),
because there are enough x86 registers, so there is no reason for this
error. What distro ships this gcc ?
Back when I installed this, I downloaded the tarball myself from the gcc
website. It should be the official, vanilla 3.2.2 release, unless I
screwed up somewhere. Maybe your distro fixed the bug ?

- Gerry
Stephane Marchesin
2005-08-23 22:55:36 UTC
Permalink
Post by Gerry JJ
Post by Stephane Marchesin
Frankly, I suspect you have a bug in your gcc version (it looks to me
like it has been pulled from cvs, where they usually break such
things), because there are enough x86 registers, so there is no reason
for this error. What distro ships this gcc ?
Back when I installed this, I downloaded the tarball myself from the gcc
website. It should be the official, vanilla 3.2.2 release, unless I
screwed up somewhere. Maybe your distro fixed the bug ?
Probably. Hmm, I'm not sure what to do.
Does anyone else have a gcc 3.2.2 ? And does it trigger the bug too ?

Stephane
John Ratliff
2005-08-21 21:21:21 UTC
Permalink
This happened for SDL-1.2.8, too, but I thought I'd mention it. During
configure, I get this warning:

/home/jdratlif/SDL-1.2.9/missing: Unknown `--run' option
Try `/home/jdratlif/SDL-1.2.9/missing --help' for more information
configure: WARNING: `missing' script is too old or missing

Also, the SDL-1.2.9 win32 pre-packaged DLL on your site doesn't work
with my SDL app. It says the application failed to initialize properly.
The pre-packaged SDL-1.2.8 win32 DLL seems to work just fine though.

If I compile my own DLL, I can use 1.2.9. I'm using mingw/g++ 3.4.2 on
Windows XP.

The source to my program is at http://code.technoplaza.net/temp/wx-sdl.cc.

However, it requires wxWidgets in addition to SDL. There is a win32 zip
file binary at http://code.technoplaza.net/temp/wx-sdl.zip if you just
want to see the error message with your pre-packaged SDL-1.2.9 win32 DLL.

--John Ratliff
Sam Lantinga
2005-08-22 03:36:15 UTC
Permalink
Post by John Ratliff
This happened for SDL-1.2.8, too, but I thought I'd mention it. During
/home/jdratlif/SDL-1.2.9/missing: Unknown `--run' option
Try `/home/jdratlif/SDL-1.2.9/missing --help' for more information
configure: WARNING: `missing' script is too old or missing
Yes, I fixed this earlier today, thanks.
Post by John Ratliff
Also, the SDL-1.2.9 win32 pre-packaged DLL on your site doesn't work
with my SDL app. It says the application failed to initialize properly.
The pre-packaged SDL-1.2.8 win32 DLL seems to work just fine though.
Okay, thanks for the feedback!

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Sam Lantinga
2005-08-24 05:59:11 UTC
Permalink
Eric Wing has provided updated MacOS X packages:
http://www.libsdl.org/cvs/SDL-1.2.9.dmg
http://www.libsdl.org/cvs/SDL-devel-1.2.9.pkg.tar.gz

There are also MacOS 9 packages:
http://www.libsdl.org/cvs/SDL-1.2.9-PPC.sea.bin
http://www.libsdl.org/cvs/SDL-devel-1.2.9-PPC.sea.bin

See ya!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Anders F Björklund
2005-08-26 21:49:33 UTC
Permalink
Post by Sam Lantinga
http://www.libsdl.org/cvs/SDL-1.2.9.dmg
http://www.libsdl.org/cvs/SDL-devel-1.2.9.pkg.tar.gz
I see that you still don't want to provide any
"sdl-config" and "libSDLmain.a" for Mac OS X ?
(for the binary packages, without recompiling)

It would be nice to have those for the required
flags, without *having* to mess around with the
Xcode projects and Objective-C ? (if not wanted)


But OK, I guess I can provide that in my own SDL
package - along with the (supposedly rejected ?)
patches* for supporting Carbon and X11 as well...

../configure --enable-video-cocoa --enable-video-carbon
checking for Cocoa framework... yes
checking for Carbon framework... yes


Here is a screenshot for framework installer:
Loading Image...
(from www.algonet.se/~afb/SDL-Resources.zip)

--anders


* Here was the original posting, with the Mac OS X patches:
http://www.devolution.com/pipermail/sdl/2005-May/068939.html
Sam Lantinga
2005-08-24 22:16:30 UTC
Permalink
I've added the VC6 prerelease package:
http://www.libsdl.org/cvs/SDL-devel-1.2.9-VC6.zip

Here's an updated SDL.dll:
http://www.libsdl.org/cvs/SDL.dll

See ya!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
John Ratliff
2005-08-25 19:07:10 UTC
Permalink
Post by Sam Lantinga
http://www.libsdl.org/cvs/SDL-devel-1.2.9-VC6.zip
http://www.libsdl.org/cvs/SDL.dll
See ya!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
This new DLL works great. It fixed the application failed to initialize
problem I had with the last 1.2.9 pre-compiled DLL.

--John Ratliff
Sam Lantinga
2005-08-25 20:34:00 UTC
Permalink
Post by John Ratliff
This new DLL works great. It fixed the application failed to initialize
problem I had with the last 1.2.9 pre-compiled DLL.
Thanks John!

-Sam Lantinga, Software Engineer, Blizzard Entertainment
Sam Lantinga
2005-08-28 08:46:45 UTC
Permalink
Post by Anders F Björklund
But OK, I guess I can provide that in my own SDL
package - along with the (supposedly rejected ?)
patches* for supporting Carbon and X11 as well...
They weren't rejected, we just didn't feel comfortable adding them right
before SDL 1.2.9 was released, to make sure they got plenty of testing.

I believe they are in Ryan's list of patches to look at... (Ryan?)

See ya!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Anders F Björklund
2005-08-28 11:42:45 UTC
Permalink
Post by Sam Lantinga
They weren't rejected, we just didn't feel comfortable adding them right
before SDL 1.2.9 was released, to make sure they got plenty of testing.
I believe they are in Ryan's list of patches to look at... (Ryan?)
No problem, it could be scheduled for SDL 1.2.10 or something...
(maybe get some testing on Darwin as well as on regular Mac OS X)

Unoffical builds will be at http://spriteworldx.sourceforge.net/

--anders
Ryan C. Gordon
2005-08-28 19:38:23 UTC
Permalink
Post by Sam Lantinga
They weren't rejected, we just didn't feel comfortable adding them right
before SDL 1.2.9 was released, to make sure they got plenty of testing.
I believe they are in Ryan's list of patches to look at... (Ryan?)
Yes, and to put blame in the right place, I was the one that requested
they not be added for 1.2.9.

However, let's definitely put them in CVS now that 1.2.9 is shipped. If
you've got a newer version than the last posted here, please send it to
me, otherwise, I'll go forward with what I've got.

Thanks,
--ryan.
E. Wing
2005-08-28 23:08:07 UTC
Permalink
From: Anders F Bj?rklund
I see that you still don't want to provide any
"sdl-config" and "libSDLmain.a" for Mac OS X ?
(for the binary packages, without recompiling)
It would be nice to have those for the required
flags, without *having* to mess around with the
Xcode projects and Objective-C ? (if not wanted)
Hello, Sam asked me to respond to this. First, I'm not an official SDL
maintainer, so I don't make the final decisions on this, so take my
opinion with a grain of salt.

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.

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.

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

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.
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.
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.
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.

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?)
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.


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.

Thanks,
Eric
Anders F Björklund
2005-08-29 06:46:59 UTC
Permalink
Post by E. Wing
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.
Post by E. Wing
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)
Post by E. Wing
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"...
Post by E. Wing
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)
Post by E. Wing
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.
Post by E. Wing
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...
Post by E. Wing
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" ?
Post by E. Wing
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)
Post by E. Wing
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
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)
Post by E. Wing
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...
Post by E. Wing
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
Olivier Delannoy
2005-08-29 17:43:00 UTC
Permalink
Post by Anders F Björklund
Post by E. Wing
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.
Post by E. Wing
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)
Post by E. Wing
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"...
Post by E. Wing
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)
Post by E. Wing
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.
Post by E. Wing
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...
Post by E. Wing
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" ?
Post by E. Wing
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)
Post by E. Wing
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
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)
Post by E. Wing
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...
Post by E. Wing
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
_______________________________________________
SDL mailing list
http://www.libsdl.org/mailman/listinfo/sdl
I agree with most of the thing that have been told in this discussion.
I will only introduce a tool named pkg-config. It's a really simple
tool that try to provide a standard for obtaining package information
and availability. It's really easy to provide support for pkg-config
in SDL. It's not a perfect solution but it can enhance the task of the
autoconf maintainer as well as most user who use xxx-config script in
their makefile. It can be present at the same time as sdl-config
script as well.
E. Wing
2005-08-31 07:24:21 UTC
Permalink
This seemed important, so I wanted to split it into another email.
Post by Anders F Björklund
Sorry, I took that script right off my own files - that do have support
both for Cocoa ("Quartz") and for Carbon ("toolbox") video drivers...
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)
Does the patch you submitted for Carbon and X11 force us to change the
link flags for the end user? If so, I think we need to decline the
patch, unless SDL can still be compiled the old way, which would have
to be the case for the binaries we provide. I think it's just going to
break too many people who have existing build systems out there if it
suddenly requires additional link flags for the end developers. I
think the Carbon fallback isn't terribly useful as Mac OS 9 is
essentially dead and nobody is really maintaining that code. The X11
support is kind of interesting, but it's not something that I think
really needs to be enabled for outside internal use. I'm also not sure
if you need the headers from the X11 stuff. I think by default, the
developer tools does not install the X11 development stuff (runtime is
provided though), so there is the possibility that people won't be
able to build SDL with this. Since our Xcode build system doesn't have
any detection support, this support would not be enabled.

Thanks,
Eric
Anders F Björklund
2005-08-31 19:36:17 UTC
Permalink
Post by E. Wing
Post by Anders F Björklund
Sorry, I took that script right off my own files - that do have support
both for Cocoa ("Quartz") and for Carbon ("toolbox") video drivers...
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)
Does the patch you submitted for Carbon and X11 force us to change the
link flags for the end user? If so, I think we need to decline the
patch, unless SDL can still be compiled the old way, which would have
to be the case for the binaries we provide.
No, it does not.
I was under the impression that the Quartz driver required
Carbon and OpenGL anyway, so I didn't bother taking them out...

It's all flags now for configure, if you saw the actual patch.
In my local build, I have them all enabled. Doesn't have to
be that way in the default builds, can default them to "off" ?

I used this line:
../configure --enable-video-cocoa --enable-video-carbon --enable-dlopen
\
--enable-video-x11 --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib

The required libraries varies on what options you configure:

if test x$enable_video = xyes -a x$enable_video_cocoa = xyes; then
SHARED_SYSTEM_LIBS="$SHARED_SYSTEM_LIBS -framework Cocoa"
fi
if test x$enable_video = xyes -a x$enable_video_carbon = xyes; then
SHARED_SYSTEM_LIBS="$SHARED_SYSTEM_LIBS -framework Carbon"
fi
if test x$enable_video = xyes -a x$enable_video_opengl = xyes; then
SHARED_SYSTEM_LIBS="$SHARED_SYSTEM_LIBS -framework OpenGL"
fi

But I will tweak the default values and the driver order,
to make the standard "blank" ./configure match the old one.
(i.e. make Quartz the default driver and the others disabled)

Will make a new patch, against the SDL-1.2.9 release version.
Post by E. Wing
I think it's just going to
break too many people who have existing build systems out there if it
suddenly requires additional link flags for the end developers. I
think the Carbon fallback isn't terribly useful as Mac OS 9 is
essentially dead and nobody is really maintaining that code.
Maybe there was some kind of misunderstanding, but the Carbon driver
was only intended for Mac OS X. I only based it off the old one since
it's mostly the same anyway and it was easier to use conditionals...

That it happens to work on Mac OS 9 with CarbonLib is just a "bonus".

There seems to be some kind of SDL belief that Mac OS X requires
the use of Cocoa and Objective-C - while Apple has promoted their
old "porting" library now, to an alternative using Carbon and C/C++.

They can both use the .nib files that Interface Builder creates ?
Post by E. Wing
The X11
support is kind of interesting, but it's not something that I think
really needs to be enabled for outside internal use. I'm also not sure
if you need the headers from the X11 stuff. I think by default, the
developer tools does not install the X11 development stuff (runtime is
provided though), so there is the possibility that people won't be
able to build SDL with this. Since our Xcode build system doesn't have
any detection support, this support would not be enabled.
The X11 support was *mostly* intended for Darwin, to be honest...
Since it doesn't have the Cocoa and Carbon frameworks, I mean ?

But it's rather useful on Mac as a testing platform, if you want
to see how your games will look on an X11 platform - like Linux.

--anders
E. Wing
2005-08-31 07:15:46 UTC
Permalink
Post by Anders F Björklund
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.
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örklund
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)
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örklund
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 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örklund
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"...
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örklund
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)
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örklund
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.
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örklund
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...
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örklund
AFAIK, 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örklund
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.
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örklund
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 ?
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örklund
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)
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örklund
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)
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. Wing
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.
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örklund
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 ?
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
Tyler Montbriand
2005-08-31 16:16:50 UTC
Permalink
Post by E. Wing
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.
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.

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.
Post by E. Wing
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.
sdl-config is not portable to, say, windows, which can't execute sh programs.
OSX, being a UNIX with funny compile flags, can. OSX even has the standard
GNU build tools. sdl-config would be portable to OSX if it was installed.
Post by E. Wing
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.
You can't exactly have it both ways, sadly. Either give people choice or
don't. I don't really see what the problem is -- sdl-config is a tool
*designed* to help people on platforms with funny flags. Like OSX.
Post by E. Wing
(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?
Post by E. Wing
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.
It's impossible to provide consistency when installations are inconsistent,
yes. How is this a point in favor of being inconsistent?
Post by E. Wing
And when just one system doesn't support it, it can really screw you over.
And this is a point in favor of, as you say, screwing people over, how?
Post by E. Wing
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).
GNU Make and GCC come with the OSX build tools you know :) You can even link
in frameworks and build SDLMain.m from commandline. Once I figured out the
build flags needed and built my own libSDLmain.a, I was able to do everything
from ordinary makefiles.

cflags were: -DTHREAD_SAFE -I/Library/Frameworks/SDL/Headers
ldflags were: -framework SDL -framework Cocoa -lobjc /path/to/libSDLmain.a
Post by E. Wing
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.
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.
Post by E. Wing
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.
Unlike lots of other UNIX systems, /usr/local/bin is in the default executable
path under OSX. Put it there and it should work. A UNIX system without
sdl-config isn't exactly a "peaceful coexistence" from my POV; the developer
package is only directly useful if you're using xcode. What if people hate
xcode?
Post by E. Wing
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.
So why the worry about sdl-config and libSDLmain.a? They are also for the
developer.
Post by E. Wing
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.
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.
Post by E. Wing
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.)
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.
Post by E. Wing
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.
What's the point in making something that basically works harder to use?
Post by E. Wing
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.
Clashes like what? /usr/local/bin is in the normal executable path, and
nothing else is going to install sdl-config...
Post by E. Wing
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.
Antonio SJ Musumeci
2005-08-31 17:39:12 UTC
Permalink
What would be the problem with making sdl-config a simple C program
which is generated at libsdl's compile time? It would seem that then it
could be more cross platform.
Post by Tyler Montbriand
Post by E. Wing
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.
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.
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.
Post by E. Wing
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.
sdl-config is not portable to, say, windows, which can't execute sh programs.
OSX, being a UNIX with funny compile flags, can. OSX even has the standard
GNU build tools. sdl-config would be portable to OSX if it was installed.
Post by E. Wing
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.
You can't exactly have it both ways, sadly. Either give people choice or
don't. I don't really see what the problem is -- sdl-config is a tool
*designed* to help people on platforms with funny flags. Like OSX.
Post by E. Wing
(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?
Post by E. Wing
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.
It's impossible to provide consistency when installations are inconsistent,
yes. How is this a point in favor of being inconsistent?
Post by E. Wing
And when just one system doesn't support it, it can really screw you over.
And this is a point in favor of, as you say, screwing people over, how?
Post by E. Wing
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).
GNU Make and GCC come with the OSX build tools you know :) You can even link
in frameworks and build SDLMain.m from commandline. Once I figured out the
build flags needed and built my own libSDLmain.a, I was able to do everything
from ordinary makefiles.
cflags were: -DTHREAD_SAFE -I/Library/Frameworks/SDL/Headers
ldflags were: -framework SDL -framework Cocoa -lobjc /path/to/libSDLmain.a
Post by E. Wing
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.
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.
Post by E. Wing
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.
Unlike lots of other UNIX systems, /usr/local/bin is in the default executable
path under OSX. Put it there and it should work. A UNIX system without
sdl-config isn't exactly a "peaceful coexistence" from my POV; the developer
package is only directly useful if you're using xcode. What if people hate
xcode?
Post by E. Wing
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.
So why the worry about sdl-config and libSDLmain.a? They are also for the
developer.
Post by E. Wing
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.
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.
Post by E. Wing
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.)
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.
Post by E. Wing
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.
What's the point in making something that basically works harder to use?
Post by E. Wing
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.
Clashes like what? /usr/local/bin is in the normal executable path, and
nothing else is going to install sdl-config...
Post by E. Wing
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.
_______________________________________________
SDL mailing list
http://www.libsdl.org/mailman/listinfo/sdl
David Olofson
2005-08-31 18:28:10 UTC
Permalink
Post by Antonio SJ Musumeci
What would be the problem with making sdl-config a simple C program
which is generated at libsdl's compile time? It would seem that then
it could be more cross platform.
...except that it won't work with cross compilers, unless you make
sure sdl-config is compiled with the native compiler, rather than the
cross compiler. :-)

(Lost count of how many time's I've had to hack GNU libtool to do the
right thing in this case... Now the issue seems to have mysteriously
disappeared, though - probably because newer compilers don't need an
external tool to analyze Win32 DLLs.)


//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
Anders F Björklund
2005-08-31 20:55:40 UTC
Permalink
Post by Tyler Montbriand
Post by E. Wing
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.
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.
And it seems to have worked good so far. Still no framework sdl-config
:-)
Post by Tyler Montbriand
sdl-config is not portable to, say, windows, which can't execute sh programs.
Which is why one uses MinGW/Cygwin, to stay out the scary nightwinged
.bats.
Post by Tyler Montbriand
OSX, being a UNIX with funny compile flags, can. OSX even has the standard
GNU build tools. sdl-config would be portable to OSX if it was installed.
And it would even always be installed, if it was in the *offical*
package.
(not: "sure we have an sdl-config, but only if you compile it
yourself...")
Post by Tyler Montbriand
Post by E. Wing
(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?
Actually /usr/local/bin hasn't always been in the path on Mac OS X
(sadly),
and it still isn't on some Linux distros (or it comes *after* /usr/bin
?!?)

But the main reason on Mac OS X was that the .dylib-using scripts were
there.
Post by Tyler Montbriand
GNU Make and GCC come with the OSX build tools you know :) You can even link
in frameworks and build SDLMain.m from commandline. Once I figured out the
build flags needed and built my own libSDLmain.a, I was able to do everything
from ordinary makefiles.
cflags were: -DTHREAD_SAFE -I/Library/Frameworks/SDL/Headers
ldflags were: -framework SDL -framework Cocoa -lobjc
/path/to/libSDLmain.a
Yes, this is exactly what should go in a sdl-config script - to help
people out.
I wrote a first draft, but will clean it up a little to lose the
Carbon/OpenGL.
Post by Tyler Montbriand
Unlike lots of other UNIX systems, /usr/local/bin is in the default executable
path under OSX. Put it there and it should work. A UNIX system without
sdl-config isn't exactly a "peaceful coexistence" from my POV; the developer
package is only directly useful if you're using xcode. What if people hate
xcode?
I think a symlink from /usr/local/bin could work nice. Or in worst case,
one could add /Library/Frameworks/SDL.framework/Commands to the $PATH...

It's like using "env" to find the location of a program. It works nice,
if only you can find out what the current location of env itself is...
:-)
Post by Tyler Montbriand
Post by E. Wing
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.
That has been the solution so far... Or: "Xcode off, or compile it
yourself"

I think I'm on to something good for the new and improved SDL.framework,
and will even make a lickable PKG for it - once I build a new SDL-1.2.9
(http://www.algonet.se/~afb/sdl-installer.png, available in plain ZIP
too)

--anders
Anders F Björklund
2005-08-31 20:34:33 UTC
Permalink
Post by E. Wing
Post by Anders F Björklund
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)
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.
I don't think there is much incentive for Apple to support the
old formats, since having a new format means selling a Tiger ?
(so from their point of view, the Xcode 2.1 format is the best)

So "stabilizing" means that everyone moves to Mac OS 10.4,
and the problem magically disappears. I've been toying with
the idea to make some kind of plist/XML converter, but...

It's easier to a) provide three different project files or
b) use another system. My GCC Make files still look the same ?
(and there was the exact same problem before, with CodeWarrior)

Relying on a vendor format, even it's a semi-open XML-based one,
is going to hurt sooner or later. It's not *meant* to be portable.
No, using something like your CMake sounds better if that's required.
Post by E. Wing
Post by Anders F Björklund
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.
Yeah, I have another solution; which is to leave the /usr/local
to the "traditional" UNIX setup with lib/.dylib and include/.h
and instead follow the lead of the JavaVM.framework internals:
(compare insides of /System/Library/Frameworks/JavaVM.framework)

/Library/Frameworks/SDL.framework/Headers/*.h
/Library/Frameworks/SDL.framework/Resources/SDLMain.nib
/Library/Frameworks/SDL.framework/SDL [the dynamic lib]
/Library/Frameworks/SDL.framework/Commands/sdl-config
/Library/Frameworks/SDL.framework/Libraries/libSDLmain.a

Notice how they got their NeXTSpeak names instead of bin/lib. :-)

The only "problem" is that they're not in the usual paths...
(Apple fixed that by offering symlinks, for the "JavaVM" ?)
Post by E. Wing
Post by Anders F Björklund
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...
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.
Write a script to do it, and just name it InstallMe.command or
something.
Easy enough to check for the paranoid, and to double-click for the lazy
?

Or if you go the way of including them in the framework, the script
could set up symbolic links from /usr/local/bin and /usr/local/lib:

sudo ln -s /Library/Frameworks/SDL.framework/Commands/sdl-config \
/usr/local/bin/sdl-config
sudo ln -s /Library/Frameworks/SDL.framework/Libraries/libSDLmain.a \
/usr/local/lib/libSDLmain.a

That way, if you do install a "UNIX" version manually later - it will
just replace the sdl-config and the libSDLmain.a with the new versions ?
Post by E. Wing
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).
With a proper sdl-config and libSDLmain.a provided for the framework
build as well as for the "unix" build, it will be easier for command
line jocks to use the user-friendly frameworks instead of just giving
up and using .dylibs and requiring a manual install or Fink or worse ?
Post by E. Wing
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.
I know that Apple/NeXT designed the frameworks to bundle everything
into one place, but there is *no* reason for them requiring that
everyone else adopt to their lefthanded ways of doing things, always.

For instance, requiring the world to change their OpenGL includes
from the library <GL/gl.h> to the framework <OpenGL/gl.h> is just
plain mischief. They *could* have offered some symbolic links... ?

SDL is "lucky" that both use <SDL/SDL.h>, but it quickly breaks down and
you have to add the explicit -I/Library/Frameworks/SDL.framework/Headers
(but that is still better than having to rewrite all of the SDL
internals)
Post by E. Wing
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.
Just make one package with the "fully loaded" framework, then ?
(containing Headers and Commands and Libraries - inside of it)

Possibly also an Developer download, with extra docs and templates...
(i.e. just like you have it, just continue polish it a little further)
Post by E. Wing
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.
I'm staying clear of ~/Library/Frameworks for all future, since
Xcode just hates relative paths and replaced it with /Users/afb...
Not exactly portable, or even movable to another developer machine ?

Nope, /Library/Frameworks will be my "/usr/local" equivalent.
If I wasn't an admin, I could use ~/Library/Frameworks and ~
instead - and have all the fun messing around the with paths. :-P

--anders
Andras Salamon
2005-09-01 11:28:18 UTC
Permalink
Wearing my hat as a Mac OS X commandline developer, I'm agnostic about
exact paths for SDL on Mac OS X, but there are a few important details
that do need to be addressed. One of the main reasons to use SDL is for
cross platform portability, not just of the finished product but also
for the development process. Let's keep in mind that some projects not
only support multiple target systems, but have developers working on
multiple different platforms also.
Post by Anders F Björklund
Post by E. Wing
So, /usr/local would probably the best place, but it does
clash.
Yeah, I have another solution; which is to leave the /usr/local
to the "traditional" UNIX setup with lib/.dylib and include/.h
/Library/Frameworks/SDL.framework/Headers/*.h
/Library/Frameworks/SDL.framework/Resources/SDLMain.nib
/Library/Frameworks/SDL.framework/SDL [the dynamic lib]
/Library/Frameworks/SDL.framework/Commands/sdl-config
/Library/Frameworks/SDL.framework/Libraries/libSDLmain.a
Copying what the JavaVM framework does is not that useful. To minimize
yet more special hacks for Mac OS X, a solution that fits into the
existing autotools macros seems best.

Looking at the existing support in sdl.m4, there are the --prefix,
--with-sdl-prefix and --with-sdl-exec-prefix options to configure.
If sdl-config is not in the path, this would mean putting sdl-config in
one of the locations
$sdl_exec_prefix/bin/sdl-config
$sdl_prefix/bin/sdl-config
$prefix/bin/sdl-config
since these are the only alternatives that are tried. This means
something like
/Library/Frameworks/SDL.framework/bin/sdl-config
/Library/Frameworks/SDL.framework/Commands/bin/sdl-config
/Library/Frameworks/SDL.framework/some-path-string/bin/sdl-config
The "/bin/" part of the path to sdl-config is hardwired into sdl.m4, so
.../Commands/sdl-config is not going to work with the current autotools
macros.
Post by Anders F Björklund
Notice how they got their NeXTSpeak names instead of bin/lib. :-)
The only "problem" is that they're not in the usual paths...
(Apple fixed that by offering symlinks, for the "JavaVM" ?)
If they get NeXT style names then they need symlinks also, so that the
existing autotools macros will continue to work, as detailed above.

A couple of supporting comments, not relating to the above discussion
Post by Anders F Björklund
With a proper sdl-config and libSDLmain.a provided for the framework
build as well as for the "unix" build, it will be easier for command
line jocks to use the user-friendly frameworks instead of just giving
up and using .dylibs and requiring a manual install or Fink or worse ?
Indeed. Then we could tell our team of Mac OS X developers to use the
frameworks, instead of being forced to walk them through a fink install,
or trying to coordinate multiple versions of incompatible Xcode project
files with the mainline autotools build that the Linux and Windows
developers use.
Post by Anders F Björklund
I know that Apple/NeXT designed the frameworks to bundle everything
into one place, but there is *no* reason for them requiring that
everyone else adopt to their lefthanded ways of doing things, always.
Agreed. At last count I had five separate versions of the SDL and
associated frameworks scattered across my filesystem, and that was
just the copies bundled with apps that use SDL. If people want to use
frameworks in this way, it would seem to make more sense just to abandon
the whole dynamic linking enterprise and go back to static linking.
Post by Anders F Björklund
I'm staying clear of ~/Library/Frameworks for all future, since
Xcode just hates relative paths and replaced it with /Users/afb...
Not exactly portable, or even movable to another developer machine ?
I thought Xcode could use $HOME to avoid relative paths?

-- Andras Salamon ***@dns.net
Anders F Björklund
2005-09-01 13:25:41 UTC
Permalink
Post by Andras Salamon
Copying what the JavaVM framework does is not that useful. To minimize
yet more special hacks for Mac OS X, a solution that fits into the
existing autotools macros seems best.
Unless I missed something, you can't even *build* the SDL.framework
with the autotools/configure - only with the three Xcode projects ?

i.e. autotools works OK, just that it builds a dylib instead -
and installs everything in the bin/include/lib/man dirs.

"Mostly" OK, anyway, just ran into some silly bug with the default
glibtool version (1.5) on Tiger, when building as fat binaries...
Post by Andras Salamon
Looking at the existing support in sdl.m4, there are the --prefix,
--with-sdl-prefix and --with-sdl-exec-prefix options to configure.
I'm not sure what kind of effort it'll take to teach autotools
frameworks ?
I was only talking about a simple packaging solution, not more
auto-hacks.

But if someone wants to it more thoroughly, then - by all means - do
it...
(but hardcoding /bin/ like that, seems that they don't *want* it
"ported")

Seems easier to me to just do a symbolic link, from the "usual"
$PREFIX/bin/ ?
But I just gave up on using autocrud to configure SDL/OpenGL, I must
confess.
Post by Andras Salamon
Post by Anders F Björklund
I know that Apple/NeXT designed the frameworks to bundle everything
into one place, but there is *no* reason for them requiring that
everyone else adopt to their lefthanded ways of doing things, always.
Agreed. At last count I had five separate versions of the SDL and
associated frameworks scattered across my filesystem, and that was
just the copies bundled with apps that use SDL. If people want to use
frameworks in this way, it would seem to make more sense just to abandon
the whole dynamic linking enterprise and go back to static linking.
Now we are talking about different things. You are *supposed* to copy
all the frameworks to each and and every application - so that they
are self-contained and become drag-and-dropable through the Finder...

If that's how *they* want to play it, fine. But it doesn't mean it's
a very portable solution, nor that it sets a goal for everyone else...
I just wanted the framework version of SDL to support "sdl-config" too.

Then Apple can continue with their Frameworks instead of include/lib,
and you can choose which method you want to use by using different
SDL installations: (that each come with a different sdl-config script)

Package A: ("library")
$PREFIX/bin/sdl-config
$PREFIX/include/SDL/*.h
$PREFIX/lib/libSDL.a
$PREFIX/lib/libSDL.dylib
$PREFIX/lib/libSDL.*.dylib
$PREFIX/lib/libSDLmain.a
$PREFIX/share/aclocal/sdl.m4
Optional A:
$PREFIX/share/man/man3/*
$PREFIX/share/doc/SDL-1.2.9/*

Package B: ("framework")
/Library/Frameworks/SDL.framework/Commands/sdl-config
/Library/Frameworks/SDL.framework/Headers/*.h
/Library/Frameworks/SDL.framework/SDL
/Library/Frameworks/SDL.framework/Resources/SDLMain.nib
/Library/Frameworks/SDL.framework/Libraries/libSDLmain.a
Optional B:
/Developer/Documentation/SDL
/Developer/ProjectBuilder\ Extras [PB]
/Library/Application\ Support/Apple/Developer\ Tools [Xcode]

Then you can choose whether you want to use A) or B),
where A) would be provided through DarwinPorts/Fink...

But, even if you do use the alternate B) method provided by
the suggested PKG installer - you *still* get a sdl-config.

It's just being located in a pretty weirdo-looking $PATH.

And if you add that when building, your Makefile can look like:
SDL_CFLAGS = $(shell sdl-config --cflags) -DHAVE_SDL_IMAGE
SDL_LIBS = $(shell sdl-config --libs) -lSDL_image

And you can still use the framework, instead of the library ?
Post by Andras Salamon
Post by Anders F Björklund
I'm staying clear of ~/Library/Frameworks for all future, since
Xcode just hates relative paths and replaced it with /Users/afb...
Not exactly portable, or even movable to another developer machine ?
I thought Xcode could use $HOME to avoid relative paths?
I haven't checked again with Xcode 2.1 or 2.2, but at
least 1.5 and 2.0 just hated that in the file list.

I usually end up hacking the XML directly, to change it.
(find/replace is a lot faster than doing it in the GUI)

--anders
Andras Salamon
2005-09-06 14:36:19 UTC
Permalink
Post by Anders F Björklund
Unless I missed something, you can't even *build* the SDL.framework
with the autotools/configure - only with the three Xcode projects ?
Currently that's true. However, there is no reason this has to be the
case forever -- after all, Xcode is just a pretty GUI wrapper around
gcc and friends.
Post by Anders F Björklund
Post by Andras Salamon
Looking at the existing support in sdl.m4, there are the --prefix,
--with-sdl-prefix and --with-sdl-exec-prefix options to configure.
I'm not sure what kind of effort it'll take to teach autotools
frameworks ?
I was thinking of something like (in the build-app phase):

APP=<path_to_built_app_target.app>/Contents/Frameworks
FRAMEWORK=`sdl-config --prefix`
cp -pr $FRAMEWORK $APP

since this is essentially what is done by the deploy target in Xcode.
Post by Anders F Björklund
(but hardcoding /bin/ like that, seems that they don't *want* it
"ported")
It's just one extra symlink needed in the framework distribution.
Ultimately, the question is: does the framework add the symlink, or
the developer?
Post by Anders F Björklund
I just wanted the framework version of SDL to support "sdl-config" too.
Yes, I would really like to see this too.

-- Andras Salamon ***@dns.net
Anders F Björklund
2005-09-06 17:48:06 UTC
Permalink
Post by Andras Salamon
Post by Anders F Björklund
Unless I missed something, you can't even *build* the SDL.framework
with the autotools/configure - only with the three Xcode projects ?
Currently that's true. However, there is no reason this has to be the
case forever -- after all, Xcode is just a pretty GUI wrapper around
gcc and friends.
Oh, sure.
Just that's it a little "painful" to build .framework and .app without
it ?
(setting up the bundle directories, and doing the XML and copying the
files)

From what I can tell, it just does a "g++ -dynamiclib" to build the
"SDL".
With some extra features, of course, the main ones being the versioning:
-compatibility_version 1 -current_version 1
and the installation path, set up to be bundled with an .app it seems:
-install_name
"@executable_path/../Frameworks/SDL.framework/Versions/A/SDL"

You would have thought that there would be some _nice_ way of making
OS X frameworks/applications/packages, but *without* using the GUIs ?
(Writing eleventeens line of build scripts for each project, or giving
in and calling "xcodebuild" or "PackageMaker" isn't very nice - IMHO)
Post by Andras Salamon
It's just one extra symlink needed in the framework distribution.
Ultimately, the question is: does the framework add the symlink, or
the developer?
Since the movement seems to be away from the installer (and
post-install),
the SDL.framework bundle will be really really "stupid" it looks like...
At least having the script in the framework will help it not getting
lost.

So the developer will have to add it, but we could give the command ?
sudo ln -s /Library/Frameworks/SDL.frameworks/Commands/sdl-config \
/usr/local/bin/sdl-config

It's very possible that we need more than one libSDLmain.a, as well.
(one Coca with .nib, one Cocoa without .nib, one for Carbon, etc...)
The sdl-config could take parameters and return different ones to use.

--anders
E. Wing
2005-09-06 19:16:52 UTC
Permalink
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.
Post by E. Wing
(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
already.
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
path.
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.
Post by E. Wing
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).

-Eric
Anders F Björklund
2005-09-06 21:54:51 UTC
Permalink
Post by E. Wing
Post by Tyler Montbriand
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.
It isn't needed at all if you use the Carbon driver instead ;-)
But you are right, it should not be needed when including Cocoa.

BTW:
For some reason, the default sdl-config does include OpenGL too ?
Not sure if it does that on other platforms ? (besides Mac OS X)
OpenGL should always be available, just found it a little strange.
Maybe it's a side effect of SDL_loadso.c being broken earlier on ?
(i.e. not working by default on Mac OS X before it had the dlfcn)

I think it should find /System/Library/Frameworks/OpenGL.framework,
and it seems to be able to if I just omit the "-framework OpenGL"
when building the testdyngl application (but with -DHAVE_OPENGL)
So it could be something that should be changed, in the configure ?
(easy enough to use "dlcompat" on platforms before Mac OS X 10.4)
Post by E. Wing
Post by Tyler Montbriand
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
path.
Side note:
It seems like Mono install their stuff (symlinks) in /usr/bin instead,
but that does feel a bit "naughty" (probably being reserved by Apple ?)

They do have a pretty interesting little hack going *inside* their
framework:
/Library/Frameworks/Mono.framework/
Commands@ -> Versions/Current/bin
Headers@ -> Versions/Current/include
Libraries@ -> Versions/Current/lib
Mono@ -> Libraries/libmono.dylib
Resources@ ->
/Library/Frameworks/Mono.framework/Versions/Current/Resources
Versions/
But I'm not sure that mixing NeXTs and Oranges like that is the
future...


We _could_ do a link from /usr/bin/sdl-config, but probably *not*
automatic ?

Hiding it inside the bundle (in "Commands/") is a good compromise here,
IMHO.
There if you need it, simple to add an alias or symlink to put it in
the PATH.
It also works for the other frameworks, such as e.g. the SDL_image
framework ?

-I/Library/Frameworks/SDL_image.framework/Headers
-I/Library/Frameworks/SDL_mixer.framework/Headers
-I/Library/Frameworks/SDL_net.framework/Headers
-I/Library/Frameworks/SDL_ttf.framework/Headers

On the other platforms, they all live in $PREFIX/include/SDL. Not so,
on OS X:

<SDL_image/SDL_image.h>
<SDL_mixer/SDL_mixer.h>
<SDL_net/SDL_net.h>
<SDL_ttf/SDL_ttf.h>

Adding the extra includes is probably better than rewriting all other
code...

--anders

Loading...