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

[Olivier Delannoy]

On 8/29/05, Anders F Björklund <afb at algonet.se> 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)
> 
> > 2) If we do automatically place the file, do we automatically write
> > the correct the locations for the sdl-config script. The installer no
> > longer controls where the SDL.framework gets placed as that is now a
> > drag-and-drop operation through the .dmg. We would need to write some
> > detection routines for where the framework is located.
> 
> There are only two valid default locations: /Library/Frameworks
> and ~/Library/Frameworks. So the user should only need to provide
> a -F path if they have installed it in some non-standard location ?
> 
> But I do think that it would be nice if the sdl-config matched,
> but haven't written such an "improved" installer package just yet...
> 
> > By the way, your --libs  line in your sdl-config script includes
> > Carbon which isn't necessary as far as I know, and OpenGL only needs
> > to be linked if the application actually uses OpenGL. While this
> > probably won't cause any problems, I've taken my share of newbie
> > questions who don't understand what linking is and what things
> > actually need to be linked and start adopting bad behaviors based upon
> > information that tells them to link against stuff they really don't
> > need. By the limited nature of the sdl-config structure, you might not
> > be able to remove the OpenGL part, but I think you should remove the
> > Carbon line.
> 
> Sorry, I took that script right off my own files - that do have support
> both for Cocoa ("Quartz") and for Carbon ("toolbox") video drivers...
> 
> I think the OpenGL support was there due to the missing SDL_loadobject
> support, but I will compile it with a static libcompat instead I think.
> 
> Also, in the old patch it preferred a) X11 and b) Carbon which is wrong.
> If all three are available, it should use the Quartz driver (move it up)
> 
> 
> Either way, it won't be in SDL 1.2.9 and we can tweak it further ahead.
> I will do a test install packages, and see how it works out in practice?
> 
> --anders
> 
> 
> 
> _______________________________________________
> SDL mailing list
> SDL at libsdl.org
> 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.