Sdl 1.2.9 prerelease

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.On 8/29/05, Anders F Bj?rklund wrote:

E. Wing wrote:

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

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

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

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

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

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

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

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

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

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

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

While you are probably right, and while I “should” switch over from
using Make to something new and from CVS to Subversion (or something)

  • I still think it should work with the traditional systems as well ?

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

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

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

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

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

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

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

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

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

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

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

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

No scripts or funny business, just files (with correct file permissions)

  • /Library/Frameworks/SDL.framework (“SDL.framework”)
  • /usr/bin/sdl-config (“bin”)
  • /usr/lib/libSDLmain.a (“lib”)

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

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

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

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

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

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

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

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

Anyway, that’s my opinion on the issue for the official binaries. As
an unofficial, separate package (or just a separate download for just
the script with some notes), I don’t really see it as a problem. But
if Sam or Ryan say they want it in the official package, I’ll see
about adding it. But there are a few things I don’t know how to
answer:

  1. Where does the sdl-config go (/usr/bin, /usr/local/bin, in the
    framework itself?)
    (Or do we even attempt to place it in the file system, and instead
    make the user place it instead?)

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

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

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

But I do think that it would be nice if the sdl-config matched,
but haven’t written such an “improved” installer package just yet…

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

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

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

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

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

–anders


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

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

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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)

  1. 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 :slight_smile:

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

This seemed important, so I wanted to split it into another email.

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

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.

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.

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.

(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?

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?

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?

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

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.

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?

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.

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.

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

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?

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…

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 :slight_smile:
What’s the point of providing anything then? Just tell them to eff off and
compile it themselves.On August 31, 2005 01:15 am, E. Wing wrote:

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.

Tyler Montbriand wrote:> On August 31, 2005 01:15 am, E. Wing wrote:

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.

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.

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.

(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?

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?

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?

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

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.

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?

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.

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.

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

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?

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…

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

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


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

…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. :slight_smile:

(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.nethttp://www.reologica.se —On Wednesday 31 August 2005 19.39, Antonio SJ Musumeci wrote:

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.

E. Wing wrote:

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.

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 ?

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

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.

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

The only “problem” is that they’re not in the usual paths…
(Apple fixed that by offering symlinks, for the “JavaVM” ?)

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 ?

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 ?

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)

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)

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

–anders

Tyler Montbriand wrote:

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

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.

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…”)

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

GNU Make and GCC come with the OSX build tools you know :slight_smile: 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.

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…
:slight_smile:

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 :slight_smile:
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> On August 31, 2005 01:15 am, E. Wing wrote:

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.

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
and instead follow the lead of the JavaVM.framework internals:

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

Notice how they got their NeXTSpeak names instead of bin/lib. :slight_smile:
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
of Mac OS X installation paths:

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.

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.

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 @Andras_SalamonOn Wed, Aug 31, 2005 at 10:34:33PM +0200, Anders F Bj?rklund wrote:

Andras Salamon wrote:

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…

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.

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 ?

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

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.

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.

(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?

I just wanted the framework version of SDL to support “sdl-config” too.

Yes, I would really like to see this too.

– Andras Salamon @Andras_SalamonOn Thu, Sep 01, 2005 at 03:25:41PM +0200, Anders F Bj?rklund wrote:

Andras Salamon wrote:

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)

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

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

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

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

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

(And there is also that nasty issue of where to put the stuff and how not to
clash with other existing systems.)
Um, /usr/local/bin?

No, we’ve already said that it will clobber the sdl-config created by
building SDL yourself through the autoconf system. Both Anders and I
have pointed this out.

It’s impossible to provide consistency when installations are inconsistent,
yes. How is this a point in favor of being inconsistent?

As I have mentioned, there are other build systems out there that are
more resilient to these kinds of differences. sdl-config is not one of
them though.

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

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

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

As I said, I’m not opposed to letting people use an sdl-config script
if they choose. As you should already know, Anders is supplying one
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™ are not fundamentally incompatible.
I ported the latest blobwars, 1.05, to OSX and cobbled together an OSX ".app"
without needing to touch xcode with a 10 foot pole. I don’t think we need to
worry about the GNU tools going away any time soon either. Xcode can’t live
without them afaik.

I never said they were. In fact, nowhere have I said, “Thou shall use
Xcode”. As I’ve pointed out several times, there is now documentation
that explains what the gcc build flags are and how to build directly
on the command line. In fact, we now give more documentation on the
command line builds than we do with the Xcode projects :). The
discussion about frameworks/dylibs is completely orthogonal to the
issue of Xcode/gcc. And in all cases, I think we have done a good job
to support user choice, because as it stands right now, you can do it
any of these ways you choose (commandline/Makefiles, Xcode, Fink,
DarwinPorts, build youself, Frameworks).

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

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

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

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> Date: Wed, 31 Aug 2005 10:16:50 -0600

From: Tyler Montbriand
Subject: Re: [SDL] Re: SDL 1.2.9 PRERELEASE (Mac OS X)

E. Wing wrote:

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

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