Brandon J. Van Every <bvanevery <at> gmail.com>
2007-02-10 18:26:56 GMT
Ben Garney wrote:
Not sure why you cross-posted to sweng-gamedev with this; I'm more than
happy to discuss it privately. :)
The thread was from more than 2 months ago and I don't know if you're
always reading sweng-gamedev. Also I hope my responses benefit other
people as well.
Moving into more detail on CMake, these are the key areas that were
problematic to us... (I'll mention where our in-house solution was
helpful or limiting as well.)
- CMake-centric. It assumes you'll want to make project files
that reference CMake. It can be turned off, as you say, but I seem to
recall that it wasn't totally clean to do so - not gonna swear to it
and I'm sure it's been improved since I looked.
I'll relay that back to the guys.
- It also likes to leave files it makes lying around. Our
internal system doesn't do any of this, which suits our needs better.
I don't understand what you mean by this. Perhaps I should explain
"out of source" builds more clearly. If you do a build in your source
tree, it of course leaves files there. If you do an out-of-source
build, it doesn't. People doing CMake typically do out-of-source
builds and their source trees remain pristine. If the docs aren't
clear on how to do an out-of-source build, then perhaps we should
improve them.
- Limited build settings. It isn't possible to set every build
setting or configuration for every IDE, since CMake tries to present a
"generic" build environment. So if we want to enable certain settings,
Yeah, Brad said "we can add options," but if you've got tons you need,
perhaps the turnaround time on that would be unacceptable. CMake
endeavors to be a generic, common denominator, minimize-the-hassles
build environment. It does handle lotsa picky platform-specific
problems also, but it's not designed to provide precise control over
everything imaginable. In that case, I think one would have to either
hack the CMake sources directly (and the KDE guys do exactly that, and
it gets folded into CMake if it's generally useful), or develop
everything from scratch in your language of choice (as you did with
PHP).
- have custom build rules (like for lex or yacc specifications,
or assembly), it's a pain.
ADD_CUSTOM_COMMAND is the typical way of running a custom tool. My
Chicken Scheme build makes extensive use of it, i.e. there is no
inherent support for Scheme in CMake. Command argument passing got
better recently, as I was having trouble with cross-platform path
quoting issues. Brad King implemented a VERBATIM option that takes
exactly what you specify for your arguments and doesn't try to think
for you. So with this capability it should be easier to work with
external tools.
- There are some options for overriding this stuff, but since it
goes with the "generic" paradigm, it also likes to bring in assumptions
that don't always mesh well with how we're thinking about the project.
Sometimes one of the "CMake Useful Variables" will solve a problem.
But if it's in the Useful Variables, it won't be all that well
documented. We have a wiki page and currently these aren't in the
shipping docs. This is the weakest area of the CMake docs IMHO. The
mailing list generally makes up for this shortcoming. You ask about
what you need, and people tell you.
- CMake also won't generate project files that play nice with
non-public stuff, like the XBox 360 build requirements.
Is MSVC for the XBox 360 a different beast? Are nmake and/or make not
available?
- Requires a binary! Even if we wanted to ship CMake, it requires
a binary for the platform it's on & some setup/config work on each
system. We just ship a single .php file (if we need to ship it at all),
and for convenience on win32, php.exe and a DLL it requires, along with
a batch file to automatically regen things.
But php.exe is a binary...
- And because CMake is a binary altering the templates (to e.g.
work around limitations) is a pain.
I think you're saying you already know PHP.
To summarize: CMake is cool and a powerful tool
Wow, that's up from "terrible!" I'll tell the CMake devs, they'll be
pleased.
but it wasn't a fit for our particular needs. We were able
to write a simple, extensible tool that did only what we needed, and
nothing more, in a short period of time, and used that to do what we
needed. We looked at several other similar OSS tools and none of them
were what we wanted either, so I don't think this choice reflects
poorly on CMake. (Maybe it does on the OSS options as a whole?)
Not sure. If I were to point fingers, I'd say that the huge installed
base of GNU Autoconf has stunted build systems for years. I wonder how
Ant would compare, if you were developing in Java. I have no
experience with it.
Hope this helps you guys out.
Yes; some of your needs we can't address, but others we could do
something about.
Thanks!
Brandon Van Every
RSS Feed