Friday, November 07, 2008

cdart, cdart2 or cdash? no, cdash public!

Having a way to monitor the quality of your project is a nice thing. Uffe, my former boss from Motorola, will happily agree on this.

CMake comes with CTest and you can use it to run and collect the results of your unit-tests. Even more, you can use CTest to run gcov and valgrind.

Another nice feature of CTest is its ability to store in a central location these results, though this is also one of its problem: it's a bit more difficult (aka, not obvious) how to not publish your results and still get code coverage!

Also difficult is setting a server where to publish your data. Based on the CMake wiki, I have assumed (wrongly), that I need to set up a CDart server. Then I've found a tutorial about using a CDart2 server that looked even simpler. But just when I was going to start installing CDart2, I've come upon an e-mail from CDart2 mailing list that stated that both CDart and CDart2 are obsoleted and I should use CDash instead.

Lucky me I was too lazy to install any of the CDart of CDart2 servers.

Even better, you don't have to install CDash either: just register at http://www.cdash.org/CDashPublic/ and create a project (or more) there. Once your project is created, you can download an auto-generated CTestConfig.cmake file that can be dropped into your top source dir. Once that is done, you can run ctest and publish the results (from the build directory, of course) to CDashPublic.

Unfortunately, you still need a couple of tweaks:
  • none of the default CMake build types supports the flags needed by gcov. I've solved this by creating my own Maintainer mode:
    set(CMAKE_CXX_FLAGS_MAINTAINER "-g -O0 -Wall -W -Wshadow -Wunused-variable -Wunused-parameter -Wunused-function -Wunused -Wno-system-headers -Wno-deprecated -Woverloaded-virtual -Wwrite-strings -fprofile-arcs -ftest-coverage" CACHE STRI
    NG
    "Flags used by the C++ compiler during maintainer builds."
    FORCE)
    set(CMAKE_C_FLAGS_MAINTAINER "-g -O0 -Wall -pedantic -W -fprofile-arcs -ftest-coverage" CACHE STRING
    "Flags used by the C compiler during maintainer builds."
    FORCE)
    set(CMAKE_EXE_LINKER_FLAGS_MAINTAINER
    "-Wl,--warn-unresolved-symbols,--warn-once -fprofile-arcs -ftest-coverage" CACHE STRING
    "Flags used for linking binaries during maintainer builds."
    FORCE)
    set(CMAKE_SHARED_LINKER_FLAGS_MAINTAINER
    "-Wl,--warn-unresolved-symbols,--warn-once -fprofile-arcs -ftest-coverage" CACHE STRING
    "Flags used by the shared libraries linker during maintainer builds."
    FORCE)
    mark_as_advanced(
    CMAKE_CXX_FLAGS_MAINTAINER
    CMAKE_C_FLAGS_MAINTAINER
    CMAKE_EXE_LINKER_FLAGS_MAINTAINER
    CMAKE_SHARED_LINKER_FLAGS_MAINTAINER
    )
  • activate the maintainer mode (without this, you'll not get gcov data):
    mkdir build
    cd build
    cmake -DCMAKE_BUILD_TYPE=Maintainer ..
  • publish the data (you need an explicit call to ExperimentalMemCheck to get valgrind)
    ctest -D Experimental -D ExperimentalMemCheck
Not perfect, but not that bad either and now I can publish and analyze my metrics :-)

Wednesday, November 05, 2008

new lib of choice: log4cxx

During the last couple of weeks I've been evaluating various logging libs. The finalists were rlog-1.4 and log4cxx-0.10.0.

Inspired by the Panthios performance comparison, I've concocted my own performance test to decide what should I use: rlog or log4cxx. The test was also good to better understand the two libs and see what's the complexity to achieve similar results with them.

Instead of the tests from Pantheios, I've used these:
  • Scenario 0 No Logging (used to get a reference for the other tests)
  • Scenario 1 A single string.
  • Scenario 2 Several string instances
  • Scenario 3 Several numeric type instances.
  • Scenario 4 A custom type `Person`.
  • Scenario 5 A composite scenario, based on the previous scenarios.
  • Scenario 6 Multiple log channels, instantiated by a large number of objects, with messages only on a couple of channels (this should indicate the impact of having a new log channel defined in each class)
The tests were run logging to a file descriptor. To distinguish between lib performance and disk performance, the tests were run once logging to /dev/null and once to a real file.

Each test was also repeated for 2 types of logging formats: ttcc (this uses the TTCC log class from Log4cxx) and rlog (this uses a custom format logger from Log4cxx that outputs a text similar with that generated by rlog).

Though rlog was always almost twice as fast compared with log4cxx, in the end I'll go with log4cxx because:
  • support for wide chars (not needed now, but nice to have)
  • text formatting is much more flexible and C++ style
  • more storage formats
  • I liked more the way I've been able to add logging at class level (this is personal, I know, and somebody might get a simpler and nicer way to add rlog to a class than I was able to)
Hopefully, log4cxx will be fast enough for my isolib and I will not regret this decision later :)

Here are the benchmark results:

Monday, October 27, 2008

tools of choice: devtodo

Do you need some simple tool that keeps track of your todo list? Look no further: devtodo is your answer :-D

Here are some nice things about devtodo:

  • cmdline tool
  • color output on console
  • exports to HTML/XML
  • keeps track of 'done' tasks, organizes tasks and manages priorities
  • the todo file can be stored with your sources, in your git repo ;-)

Monday, July 28, 2008

malmo: checked!

Last weekend in Sweden and last important place from the neighborhood to visit - Malmo. Enjoy the view :-)

Thursday, July 24, 2008

helsingor, helsinborg and copenhagen

Here are some more picture albums from Denmark and Sweden:



Looks like after 1 month in Lund I've visited more of Denmark than after 6 months in Alborg ;-)

Friday, July 04, 2008

lund, sweden

Yesterday I've returned from the new job by foot and made some picture. Here are some of the best I've made (more will hopefully come in the future :-D ).

Friday, June 27, 2008

le roi est mort, vive le roi!

After almost 2 years, my work at Motorola is going to an end. Luckily for me, another contract is on the pipe: this one is for Axis and next month I'll be in Lund, Sweden, for training. The project is going to be on Linux, developing in C, for embedded devices.

Sunday, June 08, 2008

boost with cmake

First, make sure you are using cmake 2.6, as the boost module is much better and I've actually managed to use it on both Linux and Windows.

cmake_minimum_required( VERSION 2.6 FATAL_ERROR )


Next check for the boost installation, version a/o some libraries:

# search for Boost version 1.34
find_package( Boost 1.34 COMPONENTS regex )


Last piece to the puzzle: specify the include and lib path and link as needed:


link_directories ( ${Boost_LIBRARY_DIRS} )
include_directories ( ${Boost_INCLUDE_DIRS} )

add_executable (
helloworld
helloworld.cc
)

target_link_libraries (
helloworld
${Boost_LIBRARIES}
)


On Linux, nothing else is needed to compile your boost app. On Windows, I had to extend the path to include the boost root and lib paths. If you are using MSys, just add something like this to your .profile, for example:


BOOST_ROOT=/e/programs/boost_1_35_0
BOOST_LIBRARYDIR=$BOOST_ROOT/stage/lib

export PATH=$PATH:$BOOST_ROOT:$BOOST_LIBRARYDIR


If you need more info, just read the help:

$ cmake --help-module FindBoost

Saturday, June 07, 2008

new tool of choice: cmake

Now I have a new source control system, what about a new build system? I've been using automake and autoconf for some time and all was relatively fine on Linux, but quite a pain to use on Windows.

Again, googled some time and found some candidates. Between them, cmake. Its problem is that there is very little documentation, except a book by Kitware, the creator of cmake, with a ludicrous price. But, other than that, it does its job quite nice on both Linux and Windows and it is open-source. It is also used by quite some big projects like KDE. So why not use it myself?

new tool of choice: git

With a new PC in house, SVN started to show its limits: I wanted to have a source control system that allows me to work from any of my PC's, with minimum of hassle. SVN is fine if I would have one computer that is always on, but I don't. My old PC makes a lot of noise and heat and would prefer to keep it off as much as possible. My tablet is my current development box, but I don't want to keep a central repo there, either, as I would be forced to have the tablet on if I want to some developement on my desktop.

So, after some search on google and some time spent on wikipedia and on youtube, I've decided to adopt a new source control system: git. The Windows support is not the best, but it works fine from the command line.

Now I have a "central" repo on my desktop and a clone on the laptop. The "central" repo is more like a backup repo for the laptop. Sweet :-)

Saturday, May 17, 2008

new hardware

After some long waiting, my tablet pc has finally arrived: now I'm the happy owner of a brand new Toshiba Portege M700. I had oscillated for some time between this, a Fujitsu Lifebook T4220 and a HP Pavilion tx2000. I'm still unsure if the M700 was the best deal, but this is irrelevant now, anyway. My thanx to Portable One for it.

Monday, January 07, 2008

Happy New Year 2008

I have to admit it: after returning to Romania, I've completely stopped working on the iso engine and done almost nothing beside job and my private life. Let's hope that this yeas I'll find more time for the engine :D

Until then: Happy New Year!