[SDL] CMake gurus...

Jared Maddox absinthdraco at gmail.com
Mon Mar 25 03:28:36 PDT 2013


> Date: Sat, 23 Mar 2013 23:10:46 -0300
> From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
> To: SDL Development List <sdl at lists.libsdl.org>
> Subject: Re: [SDL] CMake gurus...
> Message-ID:
> 	<CAEyBR+X7g+mdhY3hWjHgMrw5Gd9KGVu1NX0i8MzbYSOVxKSFtg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Huh, CMake is just download and run, there isn't much more to it...
> Just make sure Visual Studio is installed too. Also other libraries
> such as PhysicsFS use CMake too.
>

Having been one of these people, I assure you, there WILL be people
(especially people trying to learn how to program) who WILL wrestle
with this simple of a system. They'll get over it, and if they run
across a well-written document that covers the TRUE BASICS (such as
WHAT a build-system is, and WHY) then they'll get over it pretty
quickly. However, they will initially wrestle with it (and having a
teacher doesn't reliably help, since the skill of a teacher at
teaching is hit-and-miss on a subject-by-subject level).

Just as importantly, these new programmers are inherently part of the
"market" for SDL. Therefor, we need to deal with them, even if only by
including a precompiled copy of CMake with the source-code.

> The only important dependency SDL has on Windows are DirectX and
> OpenGL as far as I know. OpenGL always comes bundled, and DirectX has
> started to come bundled with Visual Studio in recent versions too.
> Correct me if I'm wrong on this.
>

As far as I know you're right, but any time that I can't be bothered
to check the internet I try to word things vaguely.


> Date: Sat, 23 Mar 2013 23:42:07 -0400
> From: "Ryan C. Gordon" <icculus at icculus.org>
> To: SDL Development List <sdl at lists.libsdl.org>
> Subject: Re: [SDL] CMake gurus...
> Message-ID: <514E760F.80906 at icculus.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>

> 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.

<list of obnoxious things that we don't want to do>

> - 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.
>
>
> I understand there are technical limitations that prevent what I'm
> describing right now, but it drives me nuts that these are hand-waved
> away as social limitations ("That's not how CMake is meant to be used"
> is just a bug report that no one is yet willing to fix).
>
> --ryan.
>

Um... does XCode not natively support makefiles? Because I just
checked to make certain I was remembering right, and Visual Studio
DOES support some primitive version of makefile that looks compatible
with conditional-free makefile syntax. Apparently Microsoft uses it to
actually build Windows itself. This, I think, should be enough for us
to bootstrap a platform-agnostic build system off of, which is why I
mentioned make in the first place.

Personally, I just don't like that make has built-in customizations
for it's "build system" role, and worry that building a cross-platform
build environment would be a pain, since we couldn't bootstrap off of
someone else's work.


> Date: Sun, 24 Mar 2013 00:57:46 -0300
> From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
> To: SDL Development List <sdl at lists.libsdl.org>
> Subject: Re: [SDL] CMake gurus...
> Message-ID:
> 	<CAEyBR+VRUX_v7fQwbYowbV1fsHsR345K609mrJdw8+ZF_XdKZA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Wouldn't the situation end up being exactly the same on Linux too?
> CMake isn't installed by default either, and if I recall correctly the
> idea is to ditch autotools there (though yes, I can vouch for the
> command line version of CMake being easier to get working).
>
> It seems like the problem here is teaching programmers how to use
> CMake altogether.
>

The "problem" is the lack of a GOOD cross-platform STANDARD
configure-equivalent. For my tastes such a thing would be a
logic-language (somewhat like make), but at the end of the day there
doesn't seem to be anything both standard and "clean" enough to avoid
stepping on another platform's toes (make, for example, is not what I
would want to use, though it's massively closer than ANYTHING "macro
language").


> Date: Sat, 23 Mar 2013 21:04:31 -0700
> From: Forest Hale <havoc at ghdigital.com>
> To: sdl at lists.libsdl.org
> Subject: Re: [SDL] CMake gurus...
> Message-ID: <514E7B4F.2060001 at ghdigital.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I admit my solution in my projects is a hand-rolled Makefile that adapts to
> all manner of situations (and yes, essentially implements configure
> functionality) such as mingw (both native and
> cross-compiled)/Mac OSX/Linux/FreeBSD/Solaris, and then a set of Visual
> Studio projects and an xcode project that tend to lag behind badly.
>

Do you think that it could work on a make that doesn't support
conditionals? Have you tried running the makefiles in Visual Studio?
Since Sam's apparently thinking about dropping CMake, that might be
useful as an alternative.

> I've found cmake very unwieldy as a "user" personally, it scares me each
> time I have to deal with a lib using cmake, it's not well explained (even by
> its own documentation), the workflow of building
> something with cmake is not readily obvious to a non-believer as it were.
>
> Plenty of horror stories with autotools as well and I'd never recommend it
> either.
>

A few months ago I was told by some devs on the MSys/MinGW mailinglist
that I shouldn't be afraid (or something like that) of the autotools
system because it would only take a little while (a week, I think?) to
learn it. Suffice to say, I disagreed with the reasonability of that,
since I implemented what I needed in a fraction of the time they
suggested, AND made it more generic than I personally needed.

> It seems that there's a lot of demand for something that just generates
> sensible VS projects, XCode projects, and a gmake Makefile for various uses,
> but I'm not sure that cmake set out to be that something.
>

No, if it doesn't support relative paths then I'd have to say that
CMake isn't such a valuable tool.


> Date: Sun, 24 Mar 2013 12:15:14 +0100
> From: Kai Sterker <kai.sterker at gmail.com>
> To: SDL Development List <sdl at lists.libsdl.org>
> Subject: Re: [SDL] CMake gurus...
> Message-ID:
> 	<CACtHX9xok0g35Z=t2m02AzHuWgPxiefmf7JzM0-EZ4WHrgMD=A at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>

> So in my opinion, switch to CMake, drop the prebuild IDE projects and
> educate the few that may need it how to run CMake. Maybe provide a few
> batch or shell scripts that invoke the cmake command line tool with
> the appropriate switches.
>
> My 2?,
>
> Kai
>

If we provide two "build folders" then we don't actually have to do that:

1) We stick a standard makefile/xcode project/vc project/etc. in one
folder. On "compilation" it calls CMake with the correct arguments (I
know that this should be possible in Visual Studio, because DGD uses
Flex & Bison from the commandline in precisely this way), and CMake
does it's thing.
2) The user then exits that project, and opens the project in the
other build folder. THAT project contains an auto-generated project
that was created by the first project. This second project results in
SDL 2 being compiled.


> Date: Sun, 24 Mar 2013 13:09:27 +0100
> From: Marcus von Appen <mva at sysfault.org>
> To: SDL Development List <sdl at lists.libsdl.org>
> Subject: Re: [SDL] CMake gurus...
> Message-ID: <20130324120927.GB1237 at medusa.sysfault.org>
> Content-Type: text/plain; charset="us-ascii"
>
> On, Sun Mar 24, 2013, Ryan C. Gordon wrote:
>

>> I understand there are technical limitations that prevent what I'm
>> describing right now, but it drives me nuts that these are hand-waved
>> away as social limitations ("That's not how CMake is meant to be used"
>> is just a bug report that no one is yet willing to fix).
>
> This is not a social limitation, but excatly the "meant to be used"
> reason. CMake is a meta build tool, trying to fit the target platform as
> good as possible, not a generic all-purpose build tool. If you want pure
> build tools, stick to the autotools, make, VC projects, XCode projects,
> and so on. Please be aware to maintain all of those properly at every
> point of time and development (which is, what cmake does (and only
> that)) ;-).
>

> Cheers
> Marcus

Actually, I'd personally say that it IS a social limitation. CMake was
written by a group that wants you to install it, and thus they (at
least seemingly) haven't paid attention to those who want it to create
portable build files. As far as I'm concerned, a project that doesn't
understand why I would want to generate my own build files needs to
step back a few steps, but at the same time I think that build files
that you can use without jumping through even the small hoop of
installing CMake are a perfectly reasonable goal.


> Date: Sun, 24 Mar 2013 12:15:06 -0300
> From: Gabriel Jacobo <gabomdq at gmail.com>
> To: SDL Development List <sdl at lists.libsdl.org>
> Subject: Re: [SDL] CMake gurus...
> Message-ID:
> 	<CAKDfesmKqrZoyGk_zBqGdtuMevEaoGLwke-oZ++UyW9O2btFGA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 2013/3/24 Ryan C. Gordon <icculus at icculus.org>
>
>>
>>  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.
>>

>> 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:
>>
>>
>
> Anyone with premake [1] experience? On paper it looks like it fits the bill
> exactly, and it's small enough that it could be beaten into our mold should
> it try to resist us :)
>
>
>
> [1] http://industriousone.com/premake
> --
> Gabriel.

I'd just like to repeat this. Has anyone used this? Any experience with it?


> Date: Sun, 24 Mar 2013 10:12:57 -0700
> From: Sam Lantinga <slouken at libsdl.org>
> To: SDL Development List <sdl at lists.libsdl.org>
> Subject: Re: [SDL] CMake gurus...
> Message-ID:
> 	<CACC3sbGrqAdT7AcS2A=5KhkC789bgsDve1oVhdQOn2-+4FqC8w at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> So at this point I don't see what cmake is buying us.
>
> Pros:
> * ?
>

One pro is:
* Less obnoxious/sprawling / More modern autotool replacement.

> Cons:
> * Additional build dependency on all platforms

> * 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

These do dampen the value of it, though.

> * Needs additional coding to support build steps and special features of
>   existing projects
>

Not having written CMake files, is this any more difficult than it
would be for a makefile?


> Date: Sun, 24 Mar 2013 17:48:36 +0000
> From: Tim Angus <tim at ngus.net>
> To: sdl at lists.libsdl.org
> Subject: Re: [SDL] CMake gurus...
> Message-ID: <20130324174836.9bfd3805e456a7731a859483 at ngus.net>
> Content-Type: text/plain; charset=US-ASCII
>
> On Sat, 23 Mar 2013 23:42:07 -0400 Ryan wrote:
>> I understand there are technical limitations that prevent what I'm
>> describing right now, but it drives me nuts that these are hand-waved
>> away as social limitations ("That's not how CMake is meant to be
>> used" is just a bug report that no one is yet willing to fix).
>
> It sounds like what you really want is something that sits on a server,
> watching the hg repository. Whenever it spies a change to
> CMakeLists.txt (or whatever other build system generation tool is
> used), it goes ahead and builds a set of build system files for each
> platform, then makes a new commit.
>

Yes. And personally, I'd say that's likely to be one of the more
desired tools for a wide variety of projects, especially anything
intended to be platform-independant. The problem with CMake is that it
doesn't create build-system-files that are easily movable.



More information about the SDL mailing list