I've just updated my cmake-lint project with version 1.2. This fixed a bug that I introduced when I added in the ability to specify defaults in a .cmakelintrc file. This was one of those silly errors that using a compiled language would have caught, but in the end better unit tests would have caught it too. I'm not really a rabid TDD-weenie but automated tests that check for basic breakage are really handy. Python makes it dead easy to mock out unwanted and unrelated code too. Unit testing C++ is hellish in comparison.
As I was saying, cmake-lint is a really basic lint tool to root out common bad practices in CMake files and suggest some better practices. It also comes with some handy Vim plugins for working with CMake. One is a better version of the omni completion code I previously posted. The other is a :CMakeHelp command that helps you learn what all the CMake commands mean. There's no documentation for these plugins, but it should be obvious how they work. In Vim, type :CMakeHelp followed by the name of a command, or partial name and tab to complete. When you edit a CMakeLists.txt file, type CTRL-X CTRL-O to start up the omni completion.
I wrote these Vim scripts because CMake is a pretty good build system but there aren't that many IDE tools available. Actually, CMake is about my favourite build system ATM, it's quite a close call with Waf though. CMake's cross-compiling is probably what just pips Waf for any new stuff I do.
CMake lets you set up a regular build that compiles for the PC, and just by passing in the name of a file that describes a different compiler via the command line you can compile the same code for the DS. With Waf you have to faff about writing more code, cloning environments, fiddling with variants... That gets a bit messy and it's all manual, especially if you want to compile with debug flags too.
Waf does ease the pain of integrating multiple modules inside the same source tree though, and it doesn't compile templates down to Make (which seems slightly crazy). Although gyp also does similar craziness for Google Chrome, but converts python templates to Makefiles, SCons input files (!) or proprietary IDE project files. Makes you wonder why they didn't just go with CMake and add to it. I would have liked to have seen a CMake generator that spat out SConstructs, for example.
Monday, June 15, 2009
Subscribe to:
Post Comments (Atom)
A bit of a late reply, but I just came across this. Indeed, gyp is yet another meta-build system that can autogenerate projectfiles, similar to cmake and premake.
ReplyDeleteA quick comment on Gyp versus cmake based on the arguments made here:
gyp versus cmake
The two main reasons stated were that
>>cmake only supports absolute paths
This is not entirely accurate, because cmake can create projectfiles (MSVC, Xcode etc) with relative paths when you use the option CMAKE_USE_RELATIVE_PATHS. Unfortunately cmake has some bug related to pdb files still using absolute paths, although there is a patch available that fixes it.
>>users have to install cmake in order to build stuff
You can use cmake to generate projectfiles, and include them in the tree, using the MAKE_SUPPRESS_REGENERATION option.
Then developers don't need cmake installed. But if your project already requires python, it makes sense to use something like Gyp. I've been using cmake for a few years now, and my main issue with it is that it is hard to customize: it requires recompiling your custom version of cmake.
As both Gyp and cmake are meta-build systems, it might be possible to auto-generate/convert from one to the other.
Cheers,
Erwin
The CMAKE_USE_RELATIVE_PATHS thing is apparently not really supported:
ReplyDeletehttp://www.cmake.org/pipermail/cmake/2009-November/033456.html
"It just does not work, and frustrates people." says Bill Hoffman.
I think relying on having the cmake program installed is probably a good idea anyway, you can then use its cross-platform features for file manipulation, directory creation and so on.
Gyp really misses out the whole "configure" step AFAICT and is tuned for Chrome-ium only, so it is probably less useful for open source projects.