[SDL] CMake gurus...

OKUMURA Yuki mjt at cltn.org
Sun Mar 24 12:07:49 PDT 2013


2013/3/25 Sam Lantinga <slouken at libsdl.org>:
> So at this point I don't see what cmake is buying us.
>
> Pros:
> * ?

- Flexibility
CMake supports Ninja( http://martine.github.com/ninja/ ); an awesome
buildtool which provides acceptable build performance on Win32.
I personally feel its Ninja support is just enough reason to implement
CMakeLists.txt...

CMake allows working with 'tip' of SDL and my own set of compiler configuration.
Pre-generated MSVC/XCode project files do not allow this.

- Modularity
CMake allows embedding another project into user's own project.
If the SDL app project driven with CMake, just "add_subdirectory(
PATH_TO_SDL_SRC sdl)" would allow to build SDL itself side-by-side.
It is useful for me because I can squeeze executable with link time
optimization.

Every other choices(Autotools, MSVC, XCode and Android *.mk) also
allow such build configuration, but this one is portable.

> Cons:
> * Additional build dependency on all platforms
> * Not as well supported in debian build environment

These are true, but there are several CMake only projects(e.g. KDE,
OpenCV, Eigen).
Several projects supports both(e.g. BulletPhysics, LLVM) with custom
integration script.

> * Not as easy to change configuration parameters

It should be as easy as autotools build;
e.g.) To change optimization level to Release:
  "cmake -DCMAKE_BUILD_TYPE=Release ."

They doesn't provide eqv. of "./configure --help" but they have
cmake-gui or ccmake.

> * Can't pre-generate Visual Studio projects for end users
> * Can't pre-generate Xcode projects for end users

I agree these are biggest problem on CMake, it seems CMake was not
designed for such use-case.
Gyp( http://code.google.com/p/gyp/ ) has better solution here for example.

-- oku



More information about the SDL mailing list