More CMake oddities…

The story continues…

I’ve got the thing working, and am now working on packaging. This is where things get far messier than they should.

First off, the default source generators are for tar.gz, tar.bz2, and tar.Z. More than I need, but OK. Messing with it means I need to mess with it for ALL target platforms, and that seems to defeat the purpose. Where things go seriously awry is when the second generator runs, in that it also hauls in the first archive, and the third hauls in the first two. Even more seriously, they haul in their working directory with FULL copies and all temporary files. Run this more than once, and you quickly run out of disk space. And of course, CMake provides no functionality for removing these old temp files.

Yes, you can work around these. But why? This is some pretty basic stuff! My ~11000 lines of code quickly turned into an archive over 800 MB! That’s too big for a CD!

The second issue is when I try to build a RPM from a source file. This is a process that needs to be non-interactive, but that’s not how CMake is designed to run. The Fedora guidelines for create a .spec file using CMake don’t work. The primary problem is CMake just wont work if your current directory is different from the one used to make the archive, which it is pretty much guaranteed to be. Defining the appropriate variables on the command line doesn’t seem to override the cache conflicts. The workaround seems to be to create a script file to do this, but I really should be able to all that from the command line.

The more I play with CMake the more I’m convinced that it could be a good system some day, but it’s not there yet. I’ll continue to use it for small projects that might require a windows build, but there’s no way I’m ready to convert my larger packages. CMake is far from ready for that. They seem to have tackled some of the larger autoconf/automake issues, but have ignored so much basic stuff along the way.

CMake – an almost fulfilled promise

OK, so I said it was on the back burner. It was, for a few hours. I hate to be beaten though, so I went back at it.

As always, when changing systems, thinking has to change with it. There were a few things I had to modify, such as the install directive for the library. Turns out it also needs an ARCHIVE destination even when building shared libraries. The main one is a major “Duh!” of dealing with shared libraries. Here’s an excellent site that can explain it far better than I would: http://www.vtk.org/Wiki/BuildingWinDLL.

So now everything builds fine and links fine. The next step is registering the DLL so I can use it!

I still think CMake is going to be a challenge for some of my existing projects, but I’m liking it more and more. The documentation needs work though (says the guy who hates to document).

CMake – an unfulfilled promise

As I progress with the development of a C++ queuing model library, the prospect of creating yet another build environment for compiling on Windows loomed its ugly head. CMake promises to make these cross-platform builds doable, and as the build system for the library is still simple, I thought I’d give it a try.

The first step was on the Linux side where all works fine. It took a little doing, but not too much. The only real hiccup I had was in figuring out how to set the library version numbers. All in all with a bit of web trawling, it took me only about 4 hours from scratch to a system that matched my current automake/autoconf system. Granted, it’s a simple configuration, but that’s a lot to replace. I was impressed.

Moving it to Windows (Windows XP with Visual Studio Express 2009) was less successful. I need platform dependent directives for my test program link options. The target directive had to be removed in its entirety due to a lack of destination directive even though it’s clearly there. I haven’t tested how that will work on Linux, but I’m sure its not good. There’s also the problem of the test files. I built a shared library, and the tests link against this. Except they don’t. They want a static library. So I try to build both. It doesn’t. My square peg just doesn’t want to fit in this round hole.

Now, as I’ve already mentioned, I haven’t spent much time on this yet. I’ll continue, but for now, it’s on the back burner. Sigh.

“Apple Tax” highlights the reality of the “Windows Tax”

I’m by no means a Mac fanboy, as you might gather from my previous post. I have many machines, and only one is a Mac – my laptop. My long standing Windows dislike aside, when I bought it I shopped around, and a comparably priced Windows box was much more expensive, with the OS being one of the more expensive parts of the equation. Given that my Intel boxes have mostly run Linux for years, the fact that I can’t buy a machine without buying Windows makes it an instant Windows tax. But lets put that aside for the moment and talk about the latest Redmond rant. Comparing similarly speced machines, Windows always loses.

Here’s a good analysis: http://www.theregister.co.uk/2009/04/11/microsoft_flames_macs/

Now this wasn’t always true. There was a long period of time when the Mac would have been a half-decent machine for a third of the asking price. And that ignores the fact that the only way to fix Mac issues was to reinstall the OS at regular intervals. But those days have passed. OS X is a solid consumer operating system, if a little annoying for enterprise developers like myself. And the alternative is never Windows.

For the record, I currently have 9 machines, 4 running Solaris, 4 running various flavours of Linux, and one Mac. Plus numerous Linux instances I use for development running as virtual machines. I do run a licensed copy of Windows, but I run that using VMWare and haven’t powered it on in months. I’ve used WIndows extensively over the years. My first OS was TRS-DOS, which was written by Microsoft, before moving to DOS 2.0, which wasn’t, on an original IBM PC. My first Windows version was 3.1.

It’s nice to use the computer instead of fighting the OS.