VisualBoyAdvance-M

The SDL version of VBA-M does not compile out of the box on OS X, even if the machine has cmake installed (cmake does not come standard on OS X). I have added two files and modified the CMakeLists.txt so that the SDL version compiles on OS X. I attached a patch to this topic, which is current as of revision 671.

 

I have only tested this on an Intel Mac running 10.5.3 (the latest version) as of this date. To get it to compile, first install cmake on the machine, either through MacPorts, fink, or by downloading and compiling it from the official cmake site, then cd into the vbam directory and run:

 

cmake .

make

sudo make install

 

(Obviously, keep in mind all the usual security stuff involving sudo.)

 

This will install vbam in /usr/local/bin and the configuration file in /etc

 

As of the current revision, sound does not seem to be working, so don't be alarmed if you get no sound.

Is that Cocoa stuff really necessary ?

All the other SDL apps I know don't need that to work on macosx. The whole point of SDL is doing OS / hardware abstraction to avoid system specific code. The SDL port should work out of the box on OSX (it even works on Windows ...). My take : use one of the portable GUI (QT / GTK+) ports, write a real cocoa frontend or use the bare SDL build.

Yes, it is necessary. If you look at this entry in the SDL FAQ, you'll see that without SDLMain.m, the linking of the program will fail:

 

http://www.libsdl.org/faq.php?action=listentries&category=7#55

 

It would be possible link against libSDLMain.a, but this is merely a precompiled version of SDLMain.m. The reasons not to do this are twofold: First, as far as I can tell, cmake sets $SDL_LIBRARY to "-framework SDL -framework Cocoa" instead of "-lsdl -lsdlmain", which is what it is set to on *NIX and Windows. This is done so that it uses the pre-compiled frameworks that you can download from the official site, rather than having to compile and install SDL yourself.

 

Second, there are various options that you can set in SDLMain, such as using a nib or not, which are not available if you merely link to libSDLmain, and there are a number of modifications you can do to, for example, make sure command-q always quits. In short, it's much more flexible.

 

Although SDL is supposed to be as possible as possible, in practice, there are always some gotchas. It's not possible to use hardware surfaces in OS X unless the application is fullscreen. It is possible to use OpenGL windowed though. The pre-compiled frameworks that you can download also don't include libSDLmain, as they do on other platforms, but do include 3 different versions of SDLMain.m and SDLMain.h. As such, it is pretty much standard practice on most SDL projects with OS X ports to use SDLMain.m.

Sorry for the double post, but I read into the CMake documentation a bit more and found out how to manually link to -lSDLmain on OS X. This will remove the need for SDLMain.m/h. I have attached a patch.

 

The drawback is this way, anyone who wants to compile vbam on OS X has to compile SDL from source. They can't use the binaries provided from the SDL Web page. It doesn't matter to me either way, since this is just for the command-line SDL port, and chances are that anyone who wants to compile that can compile SDL pretty easily.

Ok, that's much better. Now CMake should do that by itself. What does "sdl-config --libs" returns ?

If sdl-config is not found, make sure you installed SDL in the correct folder.

"sdl-config --libs" returns "-L/usr/local/lib -lSDLmain -lSDL -Wl,-framework,Cocoa" but this is only because I have compiled SDL myself. Anyone who has installed the frameworks from the SDL Web site won't even have sdl-config. Because of this, CMake doesn't even run sdl-config. This is a frameworks vs. libraries thing, and CMake prefers frameworks. I even tried the documented way to get it to ignore frameworks with no results. The SDL flags for OS X are hard-coded into CMake.

Ok, I suppose it would work if you removed the SDL framework version, but your patch is not invasive anymore so I commited it.

I removed the gcc 4.2 part because I suppose it is not available with older versions of OSX. If you want to override the compiler, pass those variables as arguments.

As is, it doesn't matter if gcc 4.2 isn't available on older versions, because -mtune=native is not supported on gcc versions < 4.2. This is true for all platforms, but gcc 4.0 is the default on OS X, and Apple has not provided a gcc_select script to set the default version, making it difficult to do so. I have also found that the official VBA sources actually cause older versions of Apple's gcc to crash when compiling, though I do not know if the same would happen with VBA-M.

 

In addition, gcc 4.2 is availiable for 10.4 (Tiger), which was released back in April 2005. There are so few people using a pre-Tiger OS that it doesn't seem worth changing the mtune behavior for everyone just to get it to compile (maybe) on older systems.

Ok, anyway I wanted to remove mtune=native because it makes the job harder for packagers. Prebuilt binaries have to run on all systems, not just the one they were built on. GCC 4 shouldn't be a requirement. Some Linux distros are still GCC 3.4 based.

Sweet deal. It now compiles and runs just fine out of the box on OS X.