SDL2 Moving to CMake?

SDL Development
61

I actually used to use python for all my build scripts… but I
started time tracking and was horrified at the amount of time devoted
to ‘fixed build’ and ‘fixed build script on XXX again’ tasks I gave it
up completely and started looking for new tools.

Have you used / heard of ninja?
http://martine.github.com/ninja/manual.html

I had never heard of this; it’s a nifty tool for building large
projects and handling incremental builds… but I doubt I’d ever have
the time or patience to learn how to use it. Now, though?

cmake …/proj -G "Eclipse CDT4 - Ninja"
make

BAM. done, using ninja now. Xcode support?

cmake …/proj -G Xcode
make

Visual studio?

cmake …/proj -G "Visual Studio 10"
make

You get these synergies when you build on the tools that other people
are using to do new things with.

Raw makefiles, custom build scripts and autotools are not things that
you get these benefits from (for whatever reason).

I’m … not exactly sure what point you were making there, but I read
it as: Try new things! …and I totally agree with that; there are
people doing interesting and useful things out there in the
compiler-program-space, and sticking with old school technologies that
simply because they already exist isn’t the answer.~
Doug.

On Mon, Aug 20, 2012 at 6:42 PM, Christian Leger <chrism.leger at gmail.com> wrote:

I completely agree that maintainability is important, and at my previous
employer that boiled down to ‘out of our 30 guys in the programming team,
having the one guy who knows more than a trivial amount about our build
system is better than zero guys’ … and nobody seemed concerned about the
long-term importance of having regular coders be able to jump into and
modify the system. It was definitely a case of preferring to think we’re
saving money by not overhauling our system (migrating to CMake, or waf, or
something else entirely) yet paying a non-trivial cost every time we needed
something new out of the ol’ pile of makefiles.

While no doubt it would be illuminating (yet be a digression meant for some
other forum) if I requested supporting evidence for claims like ‘procedural
languages are a bad fit for X’ - I suspect the real reason for such belief
is that people are easily tempted to think a problem is ‘solved’ if
so-called mature projects have been the de-facto go-to solution for long
enough. Solved? Maybe, with reservations. The best we can do – and for all
criteria? I doubt it.

I think maintainability of any system is as dependent on its underlying
design as it is on any special property of Make. While prolog-style logic
can prove adequate for certain problems, that in no way justifies all the
hurdles one encounters when trying to use Make.

When you’ve taken the time to learn something, especially something arcane
that makes you valuable to those who don’t share that knowledge, it’s
understandable that you don’t want this niche you’ve carved for yourself to
evaporate into nothing. But our technologies are in many ways still in their
infancy. Look at the number of people who are still actively trying to solve
this ‘solved’ problem (and this number seems to be growing over time). I
think that’s a strong indicator that there is progress yet to be made, and
this kind of conversation - making suggestions, even trying things (which I
intend to do in the medium term) and seeing what sticks - is to the benefit
of all interested parties.

I make several of my points because I’m an unabashed optimistic futurist,
and while I dream of improving everything I can, and try when I see
opportunities, I certainly don’t dare take away anybody’s right to continue
with what works for them. I’m simply VERY interested in constructive
discussions which might, at some point, lead to build systems that seem more
natural to those of us that have struggled with make, yet can imagine in
their very own heads a system that would work for their current needs.

Of course, in the case of SDL, if existing tools are unanimously judged to
be (or according to the people who decide) unimprovable, then they will stay
right where they are.

Regards,

Christian

On Mon, Aug 20, 2012 at 3:32 AM, Jared Maddox wrote:

Date: Sun, 19 Aug 2012 15:06:41 -0400
From: Christian Leger <chrism.leger at gmail.com>
To: SDL Development List
Subject: Re: [SDL] SDL2 Moving to CMake?
Message-ID:

<CAHgimD9H8fPMj7QR4XnY=1-AEfUDpW7s89__WqVaxyYqSw3Ebw at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

<snip, synopsis: I find Make and CMake painful, and recommend Python>

I disagree. Make is (or at least started as) a logic language (like
Prolog), and having used it for a few projects, my only quibble is
that it isn’t a more generalized language. I consider procedural
languages (such as Python) to be a bad fit to what Make is used for,
because of the particular way that they’re explicit (e.g. you specify
the order of execution). If I had to use another language, I would use
either something make-ish, or shell scripts, NOT python.

As for CMake, I’ve never written code for it, so I just don’t know.

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

62

Sorry, getting carried away and being an idiot; you obviously cant invoke
make on any of those.~
Doug.
On Aug 20, 2012 9:43 PM, “Doug” <@Doug1> wrote:

I actually used to use python for all my build scripts… but I
started time tracking and was horrified at the amount of time devoted
to ‘fixed build’ and ‘fixed build script on XXX again’ tasks I gave it
up completely and started looking for new tools.

Have you used / heard of ninja?
http://martine.github.com/ninja/manual.html

I had never heard of this; it’s a nifty tool for building large
projects and handling incremental builds… but I doubt I’d ever have
the time or patience to learn how to use it. Now, though?

cmake …/proj -G "Eclipse CDT4 - Ninja"
make

BAM. done, using ninja now. Xcode support?

cmake …/proj -G Xcode
make

Visual studio?

cmake …/proj -G "Visual Studio 10"
make

You get these synergies when you build on the tools that other people
are using to do new things with.

Raw makefiles, custom build scripts and autotools are not things that
you get these benefits from (for whatever reason).

I’m … not exactly sure what point you were making there, but I read
it as: Try new things! …and I totally agree with that; there are
people doing interesting and useful things out there in the
compiler-program-space, and sticking with old school technologies that
simply because they already exist isn’t the answer.

~
Doug.

On Mon, Aug 20, 2012 at 6:42 PM, Christian Leger <chrism.leger at gmail.com> wrote:

I completely agree that maintainability is important, and at my previous
employer that boiled down to ‘out of our 30 guys in the programming team,
having the one guy who knows more than a trivial amount about our build
system is better than zero guys’ … and nobody seemed concerned about
the
long-term importance of having regular coders be able to jump into and
modify the system. It was definitely a case of preferring to think we’re
saving money by not overhauling our system (migrating to CMake, or waf,
or
something else entirely) yet paying a non-trivial cost every time we
needed
something new out of the ol’ pile of makefiles.

While no doubt it would be illuminating (yet be a digression meant for
some
other forum) if I requested supporting evidence for claims like
’procedural
languages are a bad fit for X’ - I suspect the real reason for such
belief
is that people are easily tempted to think a problem is ‘solved’ if
so-called mature projects have been the de-facto go-to solution for long
enough. Solved? Maybe, with reservations. The best we can do – and for
all
criteria? I doubt it.

I think maintainability of any system is as dependent on its underlying
design as it is on any special property of Make. While prolog-style logic
can prove adequate for certain problems, that in no way justifies all the
hurdles one encounters when trying to use Make.

When you’ve taken the time to learn something, especially something
arcane
that makes you valuable to those who don’t share that knowledge, it’s
understandable that you don’t want this niche you’ve carved for yourself
to
evaporate into nothing. But our technologies are in many ways still in
their
infancy. Look at the number of people who are still actively trying to
solve
this ‘solved’ problem (and this number seems to be growing over time). I
think that’s a strong indicator that there is progress yet to be made,
and
this kind of conversation - making suggestions, even trying things
(which I
intend to do in the medium term) and seeing what sticks - is to the
benefit
of all interested parties.

I make several of my points because I’m an unabashed optimistic futurist,
and while I dream of improving everything I can, and try when I see
opportunities, I certainly don’t dare take away anybody’s right to
continue
with what works for them. I’m simply VERY interested in constructive
discussions which might, at some point, lead to build systems that seem
more
natural to those of us that have struggled with make, yet can imagine in
their very own heads a system that would work for their current needs.

Of course, in the case of SDL, if existing tools are unanimously judged
to
be (or according to the people who decide) unimprovable, then they will
stay
right where they are.

Regards,

Christian

On Mon, Aug 20, 2012 at 3:32 AM, Jared Maddox wrote:

Date: Sun, 19 Aug 2012 15:06:41 -0400
From: Christian Leger <chrism.leger at gmail.com>
To: SDL Development List
Subject: Re: [SDL] SDL2 Moving to CMake?
Message-ID:

<CAHgimD9H8fPMj7QR4XnY=1-AEfUDpW7s89__WqVaxyYqSw3Ebw at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

<snip, synopsis: I find Make and CMake painful, and recommend Python>

I disagree. Make is (or at least started as) a logic language (like
Prolog), and having used it for a few projects, my only quibble is
that it isn’t a more generalized language. I consider procedural
languages (such as Python) to be a bad fit to what Make is used for,
because of the particular way that they’re explicit (e.g. you specify
the order of execution). If I had to use another language, I would use
either something make-ish, or shell scripts, NOT python.

As for CMake, I’ve never written code for it, so I just don’t know.

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

63

say, I haven’t heard any good justifications why a competent programmer
can’t just whip up a simplistic python program to script and define
build rules for their project.

My experience has been that whenever a project of any significant size
does this, the developers end up hating it, complaining about it
constantly, wondering why they spent an enormous amount of time building
something that turned out to be an inferior version of CMake, and
deciding they can’t ever untangle themselves from it. The simple Python
scripts rarely remain simple for long.

Although, more or less, a well-maintained solution exists that is
roughly what you describe, and it is named “Scons” … you write Python
scripts that supply source code filenames, build parameters, etc to
Scons and it figures out what to do. I found scons to be unpleasant for
several reasons, which I won’t bore you with.

–ryan.

64

2012/8/20 Ryan C. Gordon

say, I haven’t heard any good justifications why a competent programmer

can’t just whip up a simplistic python program to script and define
build rules for their project.

My experience has been that whenever a project of any significant size
does this, the developers end up hating it, complaining about it
constantly, wondering why they spent an enormous amount of time building
something that turned out to be an inferior version of CMake, and deciding
they can’t ever untangle themselves from it. The simple Python scripts
rarely remain simple for long.

Although, more or less, a well-maintained solution exists that is roughly
what you describe, and it is named “Scons” … you write Python scripts
that supply source code filenames, build parameters, etc to Scons and it
figures out what to do. I found scons to be unpleasant for several reasons,
which I won’t bore you with.

–ryan.

I agree completely. I’m actually one of those that at some point got
frustrated with CMake/Scons/Auto* and decided to just f it and build my
engine using a Python script for configuring/patching/etc. At first it’s
certainly easier and faster to develop a build system like this, as you can
do whatever you want (even what you shouldn’t) and don’t need to force
yourself into any sort of structure or learn any strange tricks that only
work when the moon is full, etc…however, it’s very clear for me now that
this strategy is useful as long as I’m the only one using it, in any sort
of distributed environment, anyone else wanting to modify my build scripts
needs to forget about a learning curve and get ready to climb a very steep
cliff. As little or as cryptic as CMake or autotools documentation may be,
it’s worlds ahead of anything I can produce for my script (which admitedly
I also kinda built without much planning ahead).
So, while they may be frustrating, and at times they seem to be secretly
conspiring you to fail without reason, in the end, for a distributed
project such as this, standarization should be top priority, that’s why
tools such as CMake should be preferred over an ad hoc script.–
Gabriel.

65

Not certain if this matters; but it’s worth noting that cmake is getting
traction in the development environment arena.
For instance, as of 6.8, Netbeans supports CMake as a build management tool.

-DanOn Mon, Aug 20, 2012 at 10:10 AM, Gabriel Jacobo wrote:

2012/8/20 Ryan C. Gordon

say, I haven’t heard any good justifications why a competent programmer

can’t just whip up a simplistic python program to script and define
build rules for their project.

My experience has been that whenever a project of any significant size
does this, the developers end up hating it, complaining about it
constantly, wondering why they spent an enormous amount of time building
something that turned out to be an inferior version of CMake, and deciding
they can’t ever untangle themselves from it. The simple Python scripts
rarely remain simple for long.

Although, more or less, a well-maintained solution exists that is roughly
what you describe, and it is named “Scons” … you write Python scripts
that supply source code filenames, build parameters, etc to Scons and it
figures out what to do. I found scons to be unpleasant for several reasons,
which I won’t bore you with.

–ryan.

I agree completely. I’m actually one of those that at some point got
frustrated with CMake/Scons/Auto* and decided to just f it and build my
engine using a Python script for configuring/patching/etc. At first it’s
certainly easier and faster to develop a build system like this, as you can
do whatever you want (even what you shouldn’t) and don’t need to force
yourself into any sort of structure or learn any strange tricks that only
work when the moon is full, etc…however, it’s very clear for me now that
this strategy is useful as long as I’m the only one using it, in any sort
of distributed environment, anyone else wanting to modify my build scripts
needs to forget about a learning curve and get ready to climb a very steep
cliff. As little or as cryptic as CMake or autotools documentation may be,
it’s worlds ahead of anything I can produce for my script (which admitedly
I also kinda built without much planning ahead).
So, while they may be frustrating, and at times they seem to be secretly
conspiring you to fail without reason, in the end, for a distributed
project such as this, standarization should be top priority, that’s why
tools such as CMake should be preferred over an ad hoc script.

–
Gabriel.

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

66

Message-ID:
<CAHgimD-d13LYjt=D6jAp4qTtKstTyr6HF8bZ4iLAw0NJATU9aw at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

While no doubt it would be illuminating (yet be a digression meant for some
other forum) if I requested supporting evidence for claims like ‘procedural
languages are a bad fit for X’ - I suspect the real reason for such belief
is that people are easily tempted to think a problem is ‘solved’ if
so-called mature projects have been the de-facto go-to solution for long
enough. Solved? Maybe, with reservations. The best we can do – and for all
criteria? I doubt it.

I think maintainability of any system is as dependent on its underlying
design as it is on any special property of Make. While prolog-style logic
can prove adequate for certain problems, that in no way justifies all the
hurdles one encounters when trying to use Make.

The only thing that justifies the HURDLES inherent in Make is “it
already works, so we don’t want to spend more time on it”. I actually
agree with several of your frustrations with Make, I just think that a
good solution would be closely related to it.

I make several of my points because I’m an unabashed optimistic futurist,
and while I dream of improving everything I can, and try when I see
opportunities, I certainly don’t dare take away anybody’s right to continue
with what works for them. I’m simply VERY interested in constructive
discussions which might, at some point, lead to build systems that seem
more natural to those of us that have struggled with make, yet can imagine
in their very own heads a system that would work for their current needs.

I can (at least somewhat) imagine such a system, I just don’t want to
spend time on it at the moment.

The Autotool/Make replacement would be largely based on Make. You
would have targets, with some code that determined if their commands
needed to be run, but unlike Make these two bits of code would both be
in a Make-dependencies/Lisp-expressions/comma-sequences format.
Conditionals would only be included in target commands, but it would
be a generic language, so no big deal. Targets specified in the
’determinant’ code could be run in whatever order the interpreter felt
appropriate, and the same would go for the contents of individual
command lines, subject only to sequence/parentheses restrictions and
line-order restrictions. Individual files could be compiled down into
another language (e.g. C) from the command line. Files could be
included, or modules (normally compiled from C) could be imported,
both within target commands. Modules would allow interaction with e.g.
SCM repositories and local databases, allowing it to slot easily into
existing systems. Standard modules would provide access to environment
variables and file systems. There would not be any automatic tie
between targets and anything else (e.g. files). There would not be any
built-ins, with the exception of “include” and “import”.

Everything else would be a support component for the Autotool/Make component.

But I don’t want to spend the time to make it, so none of this matters
all that much. I have reservations about Make (and just have NO
intentions to code for Autotools if I can avoid it), but they do the
job well enough for my current needs.

The fact that they don’t serve SDL well enough is why CMake is being
discussed. If you have any other input on CMake competitors that are
availible on multiple platforms then I really think you should post
it, but in my opinion a procedural language is not a step forward for
this task, but instead a step to the side.> Date: Mon, 20 Aug 2012 06:42:06 -0400

From: Christian Leger <chrism.leger at gmail.com>
To: SDL Development List
Subject: Re: [SDL] SDL2 Moving to CMake?