[SDL] CMake gurus...

John john at leafygreengames.com
Sat Mar 23 23:00:56 PDT 2013


cmake is more of a "windows" style autoconf. i.e., an over-complicated 
configuration dialog instead of an over-complicated bash/m4/make script. there's 
not really a win there. Just a shift in the comfort level from *nix developers 
to windows developers. In the end, it's all the same discomfort on average.

So, yes, you are seriously the only person who found cmake intuitive! :)


On 03/24/2013 01:14 AM, Sik the hedgehog wrote:
> Am I seriously the only one who didn't find CMake hard to use?
> (defaulting to the wrong toolchain aside)
>
> Then again for my projects I avoid any sort of configure-like utility
> altogether. That just feels like forcing people to build from source
> by tailoring the program to each system. I'd rather just force
> programmers to meet the system requirements and use the makefile
> directly (which in turn is as simple as it can be by not trying to do
> anything smart, just tell what files to build and what libraries to
> link with). I imagine this wouldn't be considered desirable for SDL
> though, given all the different backends it has.
>
> 2013/3/24, Terry Welsh <mogumbo at gmail.com>:
>> As a non-cmake-guru, I see the value of what Ryan is saying. There
>> have been times where I have poked around in cmake-gui doing
>> trial-and-error to try and get a usable VS project created. So that
>> seems like a nice-to-have layer to put on top of any robust solution.
>>
>> As I see it, the underlying problem is that every platform has
>> different build requirements. Cmake is still the most pleasant
>> solution to that problem that I have used. Creating a script that can
>> create projects/build scripts for all platforms sounds like it lies
>> somewhere between making something like Cmake specialized for SDL and
>> remaking Cmake. Either way, it sounds daunting and maybe redundant.
>> --
>> Terry Welsh
>> www.reallyslick.com
>>
>>
>>>> Ideally we would use something make-ish that was generic enough to act
>>>> as both a build system, AND a configure system, but I don't recall any
>>>> logic languages being standard installs anywhere.
>>>
>>> Ideally we want Windows people to find a Visual Studio project that
>>> matches their version of Visual Studio, double-click it, and build the
>>> library.
>>>
>>> Right now we're maintaining several .vcproj files for different
>>> versions, and almost universally, some subset of them fails to get
>>> updated when we change a project setting of add/remove files. Tests are
>>> missing from many of them, etc.
>>>
>>> XCode is slightly better about this, but still suffers from the fact
>>> that it's not necessarily our primary way to build SDL (even on Mac, I'm
>>> using the configure script, for example), so it isn't well-maintained
>>> either.
>>>
>>> If not CMake, something that allows us to do what CMake does is really
>>> really interesting: we maintain one text file, it spits out projects for
>>> lots of tools. But we really don't want the Windows/Mac experience to be
>>> like this:
>>>
>>> - Download SDL sources.
>>> - There's no Visual Studio project?!
>>> - Read the readme, find out I'm supposed to use CMakeLists.txt (which is
>>> the worst naming choice ever, btw).
>>> - Download CMake.
>>> - Install CMake.
>>> - Run CMake-gui.
>>> - Maybe understand I was supposed to point it at the SDL root directory.
>>> - Maybe understand I should set the output directory somewhere outside
>>> of the source tree.
>>> - Maybe understand that the poorly-built dropdown list actually scrolls,
>>> and my compiler is, in fact, supported.
>>> - Click configure (maybe twice).
>>> - Generate project files.
>>> - Launch Visual Studio with the project files.
>>> - Compile.
>>>
>>> What I'd _rather_ they do is this:
>>>
>>> - Download SDL sources.
>>> - Double-click the correct .sln file in the "VisualStudio" directory,
>>> which we generated with CMake when packaging up the sources.
>>> - Compile.
>>>
>> _______________________________________________
>> SDL mailing list
>> SDL at lists.libsdl.org
>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>



More information about the SDL mailing list