[SDL] CMake gurus...

John john at leafygreengames.com
Sun Mar 24 09:57:26 PDT 2013

The equivalent cmake sequence would be something like,

sudo make install
sudo ldconfig

You're right, it's easy to do this. The complexity is in the maintenance of the 
cmake build system, and also at the point the user wants to configure SDL2 in a 
slightly different manner.

On 03/24/2013 03:38 AM, Sik the hedgehog wrote:
> I didn't say intuitive (intuitive would be to just type "make" and
> have everything done without any more intervention), I just said easy
> :P I mean, the following doesn't look very intuitive at all, yet I
> don't have much of an issue doing it:
> ./configure
> make
> sudo make install
> sudo ldconfig
> Yep, that's what I need to do every time I have to update SDL on this
> system. The ideal thing would be to bring it down to just one command
> (or two, if you want to avoid superuser privileges until the install
> phase), but that doesn't mean it's difficult - just not obvious if you
> don't know the steps beforehand.
> At least in my experience using CMake isn't much different. I don't
> remember the exact commands right now but if I recall correctly it's
> essentially a mkdir, a chdir and then call cmake.
> 2013/3/24, John <john at leafygreengames.com>:
>> 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
>> _______________________________________________
>> 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