Mailund on the Internet

Ok, first the good news.  In the CVS version of Bio++ there is a CMake build system.  Julien tells me that they are moving to that, so that will be the future of Bio++.

Why is this good news?

Because CMake can build Xcode projects, unlike Automake.  So the CVS version of Bio++ is much easier to work with on OS X.

I still need to fiddle with the generated project files a bit to set the architecture, but aside from that it really is a breeze.

I should probably have a closer look at CMake now to start using that instead of Automake for my own projects.

All I have to figure out now is how to install the libraries from Xcode – I cannot just build the install target since I don’t have permissions for that – and how to build documentation sets.  The latter can be built from Doxygen comments, and I think that I can do that with Xcode and CMake, but I haven’t figured out how yet.

–

253-275=-22

I’m trying to get an Xcode project to play with Bio++.  I can compile just fine in the terminal if I use a Makefile, but it is annoying me that I cannot do the same within Xcode.

I’ve debugged the build process and found that the two compiler flags -D_GLIBCXX_DEBUG=1 and -D_GLIBCXX_DEBUG_PEDANTIC=1 are the sinners.

They are supposed to enable some stronger debugging code with assertions and stuff, I think, but if they are enabled I can compile my program just fine but the linker croaks on me.

It probably is something I should worry about since it could be symptoms of a problem in Bio++ (the code I’m compiling isn’t really doing anything except linking with Bio++), but right now I would be happy to just turn the flags off.

Figuring out how to do that took some time as well, but under the Target Info there is a <multiple values> under Preprocessor Macros and if I deleted that the flags went away.

Whether that is good or bad I don’t know, but at least I can build Bio++ applications in Xcode now.

I should probably try to compile the Bio++ source with an Xcode build process at some point.  It is a bit of work to port the Automake file, but if there are some issues that could be brought to light from the debug flags it might be worth it…  Anyway, I’m not up for that today.

–

253-274=-21

I’m used to comparing different revisions of my source code through diff, but XCode has a really cool way of displaying the changes between two revisions.  Pick SCM > Compare With and you get something like this:

It is just the same info as in a diff file, of course, but I find it much easier to see the changes this way.

–

103-129=-26

Andreas sent me this link yesterday:

• Using the Boost unit test framework with Xcode 3

He has just configured our HMM framework with this.   It is really nice to have the unit tests integrated with the IDE.

I am still only very slowly getting used to working with an IDE.  I have used emacs and a terminal for my programming for 15 years and I never really saw the point of an IDE.  Then when I got a Mac, I figured I should give Xcode a try.  After all, it is just a shell on top of GCC, so I can recognize the error messages and such, so the change should be manageable.

All in all, I am growing to like Xcode.  I still use Automake to set up the build system, since I want my code to compile on Linux as well (I run most of my computations on a Linux grid), but I do my editing in Xcode exclusively now.

Until now I ran my unit tests in the terminal, but it is much nicer to run them from Xcode and get directed to the test violations.

–

99-121=-22

I love the Boost library.  It is without a doubt one of the most important libraries for C++ development.  I use it in practically every program I write.

Right now, I’m working on a Mac, and I wanted to use Xcode for my programming.  Sounds reasonable, really.  It is the Apple tool for it, and since it uses the GCC tools under the hood, I am familiar with error messages and such, so it should be straightforward to use.

It isn’t!

I find it practically impossible to link with Boost.

I’ve installed Boost using the “port” tool, so it is installed the way it would be on e.g. a Linux machine.  That means that the header files are found in /usr/local/include and the libraries in /usr/local/lib.

Setting the path to the header files in Xcode isn’t so much of a problem, but getting it to link with the right library is beyond me.

As far as I’ve figured out, you need to add the right .a file.  Doing this is not so easy, ’cause the GUI won’t let you find /usr/ unless you do a bit of magic to unhide that directory.  If you manage to add the library, at least this is how it works for me, you can build the Release but not the Debug target, and even though you added a .a file, it will link with the corresponding .dynlib file, so you cannot distribute the compiled file without requireing people to have Boost installed.

How does it suck? Let me count the ways…