CMake gurus

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.

2013/3/24, Ryan C. Gordon :>

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.

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.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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.

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.

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.On 03/23/2013 08:57 PM, Sik the hedgehog wrote:

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.

2013/3/24, Ryan C. Gordon :

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.

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.


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


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

I find CMake overly complex and only use it when I need to build some
project that requires it. I use qmake for all of my projects. The files it
uses are extremely easy to use and setup, it can generate many different
kinds of makefiles/project files, and in most cases is as simple as running
"qmake" then “make”. Just a suggestion as an alternative to CMake.

The documentation on it is top notch.
http://qt-project.org/doc/qt-5.0/qtdoc/qmake-manual.html

  • Swyped from my droid.

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.

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.

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.On Mar 23, 2013 11:04 PM, “Forest Hale” wrote:

On 03/23/2013 08:57 PM, Sik the hedgehog wrote:

Wouldn’t the situation end up being exactly the s…

LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged
demo." - James Klass
"A game is a series of interesting choices." - Sid Meier


SDL mailing list
SDL at lists.libsdl.org
http://lists

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.

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

I’ve always circumvented the cmake, autoconf, VC, and xcode projects because
it’s actually easier and more reliable to simply compile the SDL sources
directly. SDL compiles pretty cleanly as straight C headers and sources. No need
for all those layers of build tools.On 03/24/2013 12:37 AM, Jonathan Greig wrote:

I find CMake overly complex and only use it when I need to build some project
that requires it. I use qmake for all of my projects. The files it uses are
extremely easy to use and setup, it can generate many different kinds of
makefiles/project files, and in most cases is as simple as running “qmake” then
"make". Just a suggestion as an alternative to CMake.

The documentation on it is top notch.
http://qt-project.org/doc/qt-5.0/qtdoc/qmake-manual.html

  • Swyped from my droid.

On Mar 23, 2013 11:04 PM, “Forest Hale” <havoc at ghdigital.com <mailto:havoc at ghdigital.com>> wrote:

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.

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.

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.

On 03/23/2013 08:57 PM, Sik the hedgehog wrote:

Wouldn’t the situation end up being exactly the s…


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer http://icculus.org/twilight/darkplaces Co-designer of Nexuiz -
http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged
demo." - James Klass
"A game is a series of interesting choices." - Sid Meier


SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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 :

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

I didn’t say intuitive (intuitive would be to just type “make” and
have everything done without any more intervention), I just said easy
:stuck_out_tongue: 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 :> 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! :slight_smile:

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 :

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

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.

Ideally, wouldn’t Windows or OSX developers want readymade
DLLs/Frameworks with an SDL project template for their IDE that lets
them start work on their own application right away? Why should anyone
be forced to compile SDL from the sources first?

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.

Shouldn’t this result in lots of complaints on the mailing list, from
the people that try to compile SDL using those projects and fail? Have
seen more requests for binaries than those (although possibly as a
result of the projects not working?).

Trying to think of valid cases why anyone would want to compile his or
her own version of SDL in the first place. Granted, as long as there
is no official SDL 2.0 release, there’s a need. But from my point of
view, if somebody is knowledgeable enough to obtain the SDL sources
from a RCS as obscure as Mercurial, wouldn’t they be also able to
check a README and have CMake generate the desired project file,
especially if the steps and settings were properly described?

Once SDL 2.0 gets official, outside from actually contributing to SDL
or making changes outside of contributing, I don’t see much need of
compiling it. Sure, it can be nice to have the source around to check
how things work exactly, or to debug in case of issues, but for that I
do not necessarily require a project for my favourite IDE (which btw.
is Eclipse CDT + gcc or MingW toolchain, and SDL never provided
projects for that).

From a personal point of view, as somebody who has used SDL 1.3 on
Linux, Windows (w/ MingW) and OSX, I was very happy with the autotools
build, as it’s the same simple steps on each platform. I’d also be
happy with CMake, as to me it seems speedier than autotools and more
flexible, although I’d probably prefer to just have it create
Makefiles.

In my own project, both autotools and CMake are available as the build
system, and the only reason to not drop autotools is that CMake is (or
at least was in the past) inferior when it comes to the "make dist"
step. I never tried generating IDE projects, though, apart from XCode
and that wouldn’t even work out of the box).

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?,

KaiOn Sun, Mar 24, 2013 at 4:42 AM, Ryan C. Gordon wrote:

Actually, there are snapshots from Mercurial which are just ZIP files
with the source code (OK, other formats available too), no need to
know about Mercurial at all. Those are also easier to build (no stupid
warning regarding not building from the Mercurial repos - the readme
isn’t clear on how to work around this, sadly).

2013/3/24, Kai Sterker <kai.sterker at gmail.com>:> On Sun, Mar 24, 2013 at 4:42 AM, Ryan C. Gordon wrote:

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.

Ideally, wouldn’t Windows or OSX developers want readymade
DLLs/Frameworks with an SDL project template for their IDE that lets
them start work on their own application right away? Why should anyone
be forced to compile SDL from the sources first?

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.

Shouldn’t this result in lots of complaints on the mailing list, from
the people that try to compile SDL using those projects and fail? Have
seen more requests for binaries than those (although possibly as a
result of the projects not working?).

Trying to think of valid cases why anyone would want to compile his or
her own version of SDL in the first place. Granted, as long as there
is no official SDL 2.0 release, there’s a need. But from my point of
view, if somebody is knowledgeable enough to obtain the SDL sources
from a RCS as obscure as Mercurial, wouldn’t they be also able to
check a README and have CMake generate the desired project file,
especially if the steps and settings were properly described?

Once SDL 2.0 gets official, outside from actually contributing to SDL
or making changes outside of contributing, I don’t see much need of
compiling it. Sure, it can be nice to have the source around to check
how things work exactly, or to debug in case of issues, but for that I
do not necessarily require a project for my favourite IDE (which btw.
is Eclipse CDT + gcc or MingW toolchain, and SDL never provided
projects for that).

From a personal point of view, as somebody who has used SDL 1.3 on
Linux, Windows (w/ MingW) and OSX, I was very happy with the autotools
build, as it’s the same simple steps on each platform. I’d also be
happy with CMake, as to me it seems speedier than autotools and more
flexible, although I’d probably prefer to just have it create
Makefiles.

In my own project, both autotools and CMake are available as the build
system, and the only reason to not drop autotools is that CMake is (or
at least was in the past) inferior when it comes to the "make dist"
step. I never tried generating IDE projects, though, apart from XCode
and that wouldn’t even work out of the box).

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


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On, Sun Mar 24, 2013, Ryan C. Gordon wrote:

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.

Ideally, the user base described below uses prebuilt DLLs, as they would
struggle with missing DirectX includes, SDK paths to be set and
everything else.

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 you describe is the worst case. Let’s take a look at other
pitfalls, which you are also trying to solve?

  • Mess up DirectX support, since I did not download the SDK previously
  • Fiddle with upgrade dialogs that might change compiler directives for
    compatibility reasons, since I use VS.NET 20XX instead of 20XY.
  • Mess around in SDL_config_XXX.h to set the necessary options and
    features
  • [insert random stuff here]

Yes, CMake is not about getting things done easily, but as platform
neutral as possible. If you want to make things easy for people, offer a
complete set of prebuilt DLLs. Those in the need to compile SDL
themselves (the minority of people for your target scenario/audience
described) most likely will be able to follow the simple instructions:

  • Download && install CMake, set it in $PATH
    [- Create a build directory in SDL/]
  • Open a cmd and execute CMake as necessary
    (or ececute the simple batch script: md build && cd build && cmake …
    [- Pass options to cmake as necessary to activate/deactivate certain portions]
  • Open the VS.NET project, build, done

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.

See my comments above. CMake is not useful for that scenario and best
would be to remove it and stick to hand-written VS projects instead.

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

The initial reason, why I wrote the CMake stuff was to enable people
(and SDL upstream developers) to get rid of the maintenance issues of
the different projects. It solves that problem. Your requirement is a
slightly different one (keep things simple), which, at the current point
of time can only be fulfilled with a good step-by-step documentation, X
percent of the users won’t read anyways, or by providing a rock solid
"click’n’run" project infrastructure at any point of time, regardless of
the releases and development.

Cheers
Marcus
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130324/4c5b4642/attachment.pgp

2013/3/24 Ryan C. Gordon

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:

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 :slight_smile:

[1] http://industriousone.com/premake--
Gabriel.

I think there are a number of good points being discussed, but as much as I
really enjoy cmake, I also understand that MSVC/Windows development feels
ridiculously different than developing for a Unix-like system. On Windows,
developers want the feeling that they can just click one or two things, and
without any configuring, get a reasonable build from a library. In Unix, I
expect to have to run into hurdles, and since I can do almost everything i
need in a few terminal commands, that’s not a problem, but Windows is
rarely setup to be easy to use like this, even when the main user is a
developer. But anyway, I don’t want this to boil down to a debate of
competence - all I’m saying is that Windows developers expect this sort of
behaviour from a library, so there is not much sense going against the
grain.

Here is what I recommend:

  • Transition away from autotools in favour of cmake - I think our cmake
    scripts could use a little work, which could be properly done if we make an
    absolute decision to drop autotools.
  • SDL release/repo side, we could MSVC projects, and run a script (I’m
    sure we could cook up some sort of python script to do this quickly and
    efficiently) to look for all paths in the MSVC xml files, and convert them
    into relative paths where appropriate. The end-developers don’t ever need
    to interact with this script, and we should clearly document if there are
    any hitches or build variables they need to be away of, since I don’t think
    we will ever get a 100% one-size-fits-all script. * There wouldn’t be
    much point in getting those developers who have issues to download python,
    because then they’d be better off just dealing with cmake.*
  • I don’t know the situation with XCode, but for now, I’ll make the
    assumption that we could do similar to the MSVC/python script fixing I
    previous suggested. I suspect it would be less complex (are paths for
    binaries like XCode fixed in Mac?), but I don’t use a Mac or XCode.
  • Linux users can generate makefiles with cmake.

CMake would always be available in case anyone from any OS/build system
wants to do some sort of custom build.

We should also regularly release MSVC binaries that would be available to
download - this is fairly standard for most cross-platform libraries that
may require extra dependencies that may not always be easy to build - I
don’t think there is a huge set of third-party dependencies in Windows for
SDL, but this is just another thing that many Windows developers expect,
and again, not because of a lack of competence - it’s just the expectation.

I think this covers all the bases. Windows developers should get a fairly
well working Visual Studio projects for MSVC 2008/2010/2012, binaries, and
everyone gets a fairly straight-forward way to build the library. CMake
remains an option for doing custom builds on all platforms.On Sun, Mar 24, 2013 at 11:15 AM, Gabriel Jacobo wrote:

2013/3/24 Ryan C. Gordon

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:

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 :slight_smile:

[1] http://industriousone.com/premake

Gabriel.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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
:stuck_out_tongue: 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 <@John6>:

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! :slight_smile:

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 :

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

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 projectsOn Sun, Mar 24, 2013 at 9:57 AM, John 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
:stuck_out_tongue: 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 :

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! :slight_smile:

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 :

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.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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.

Or maybe you could even convince the output of CMake itself to notice
that CMakeLists.txt has changed, then regenerate the set of build
system files. That’s getting all getting a bit Inception though.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).

2013/3/25 Sam Lantinga :

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

I’m pretty comfortable now since CMake can generate a Makefile project for
Code::Blocks. I don’t use Visual Studio or command-line tools on Windows,
so CMake is the reason I’m able to easily build SDL2 and port my games to
it. Personally, CMake has been a tremendous improvement over autotools.
The CMake GUI could use a lot of work, but otherwise I think it’s great.
I feel like it’s worth trying to add support for relative paths if that’s
the only really troublesome issue.

Tim, I thought CMake did notice changes to CMakeLists.txt. My generated
Makefiles do, at any rate. They re-run CMake to regenerate themselves when
necessary.

Jonny DOn Sun, Mar 24, 2013 at 3:07 PM, OKUMURA Yuki wrote:

2013/3/25 Sam Lantinga :

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


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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:10:46 -0300

From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Subject: Re: [SDL] CMake gurus…

Date: Sat, 23 Mar 2013 23:42:07 -0400
From: “Ryan C. Gordon”
To: SDL Development List
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
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
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
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
To: SDL Development List
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
To: SDL Development List
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

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 :slight_smile:

[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
To: SDL Development List
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
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.

2013/3/25, Jared Maddox :

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.

This kind of people is the one that’d rather avoid building from
source altogether (especially something like SDL which is a pretty
large framework). As somebody said before, if you want to catter to
them then providing pre-built binaries is the only reasonable option.

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

Rather than a cross-platform configure standard I’d like a makefile
standard (to the point of making configure redundant in the first
place), really, but only the most basic subset fall under that
category.