[SDL] CMake gurus...

Sam Lantinga slouken at libsdl.org
Sun Mar 24 10:12:57 PDT 2013


So at this point I don't see what cmake is buying us.

Pros:
* ?

Cons:
* Additional build dependency on all platforms
* Not as well supported in debian build environment
* Not as easy to change configuration parameters
* Can't pre-generate Visual Studio projects for end users
* Can't pre-generate Xcode projects for end users
* Needs additional coding to support build steps and special features of
existing projects


On Sun, Mar 24, 2013 at 9:57 AM, John <john at leafygreengames.com> wrote:

> The equivalent cmake sequence would be something like,
>
> cmake -DCMAKE_VERBOSE_MAKEFILE:BOOL=**on .
>
> make
> 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<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<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<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<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<http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130324/61d9bdae/attachment-0009.htm>


More information about the SDL mailing list