Howdy,
It seems that there still doesn’t exist an official way for a user to use
SDL2 in a CMake project. There’s a way to do it using pkg-config [1] but
this might not work in a Windows environment without cygwin. Another option
is to supply a FindSDL2.cmake file; this could work, but the CMake people
actually don’t recommend doing this when the package in question is already
built using CMake (see top of [2]).
An interesting option is to actually have SDL’s CMakeLists.txt file
generate a “package configuration file” that can be found and used by
find_package(SDL2). These files have the form of
"<package_name>Config.cmake". This is the recommended option if our package
is already being built using CMake. I’ve taken a stab at doing this, using
the tutorial [3] as a guide.
I have a fork [4] of SDL demonstrating this functionality. All the changes
are in the root directory:
*) CMakeLists.txt - and updated version of SDL’s CMakeLists.txt file for
generation of the package configuration files. Most of the new stuff is at
the bottom of the file.
*) SDL2Config.cmake.in - a new template file for the final SDL2Config.cmake
file.
*) SDL2ConfigVersion.cmake.in - a new template file for a script that CMake
uses to verify that the version of SDL2 being requested in find_package()
can be fulfilled by this version of the code.
For your convenience I’ve also attached an archive with the above files.
What’s cool about the way this is done is that if the user has “make
install”-ed SDL2 to a system directory, then find_package(SDL2) will “just
work”. If the user has not installed SDL2 to a system directory (useful
when doing dev), find_package() will work as long as she has supplied a
CMake variable “SDL2_DIR” that points to the directory containing the
SDL2Config.cmake file. This works both in the CMake build tree AND the
install tree!
Of course, we have CAVEATS:
*) In order to get OSX to properly link to the SDL2 shared libraries when
the libs were not installed to a system directory, I had to set a variable
called “CMAKE_MACOSX_RPATH”. This feature is super cool [5], but only works
for CMake versions 2.8.12 and later. If you’re not on a Mac and don’t have
CMake 2.8.12, you can still try this out by reducing the
cmake_minimum_required() version.
*) This all assumes that SDL2 gets built/packaged using CMake. If SDL2 was
built and installed using configure scripts, the SDL2Config.cmake files
won’t get generated and CMake users won’t be able to use find_package(SDL2).
*) I’m not a CMake expert, so the ways I’ve done things (especially
handling SDL2’s shared/static libs) might not be optimal. As I said before,
I’d love to see feedback on how to make this better/more robust.
*) I tested building SDL2 and linking it in a sample program. This works
great in OSX and Ubuntu! I’ve also tested this with Visual Studio with less
stellar results. When compiling SDL2, I get an error about a missing
library “dxguid.lib”. A hack [6] lets SDL2 compile, and then I can run the
sample SDL2 program if I copy SDL.dll into the executable directory, which
I kind of expected for Windows. Therefore this method needs more work to be
perfectly
Let me know what y’all think of this approach!
Thanks,
Luis
[1] http://duganchen.ca/building-sdl2-programs-with-cmake-and-pkgconfig/
[2] http://www.cmake.org/Wiki/CMake/Tutorials/Packaging
[3]
http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file
[5] http://www.kitware.com/blog/home/post/510
[6] http://stackoverflow.com/questions/11253383/cannot-open-file-dxguid-lib
-------------- next part --------------
A non-text attachment was scrubbed…
Name: SDL2-cmake.zip
Type: application/zip
Size: 12750 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20140304/f78454d4/attachment-0001.zip