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