[SDL] CMake gurus...

Marcus von Appen mva at sysfault.org
Sun Mar 24 05:09:27 PDT 2013

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

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

More information about the SDL mailing list