Posts Tagged ‘ CMake ’

NXT++ working, plus a Python interface

NXT++ provides a Visual Studio 2008 (VS9.0) solution file for building its library, it builds without a problem. The developers dropped support for Linux at v0.6 (v0.5 should still work).

Using the library is rather simple, I have written a CMakeLists.txt and the project was successfully built on the first try (usually not the case). The downside is that this project does not seem to be really active, the wiki is there but there’s no help, no mailing list, and no community. Oh, and it does not support the new color sensor. I am including the content of the CMakeLists.txt here in case you want to try it out:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8)

PROJECT(nxtpp-test)

FIND_PATH(NXTPP_ROOT_DIR include/NXT++.h HINTS "C:/nxtpp")

SET(NXTPP_INCLUDE_DIR ${NXTPP_ROOT_DIR}/include)

FIND_LIBRARY(NXTPP_LIB NXT++ "${NXTPP_ROOT_DIR}/bin/win32")
FIND_LIBRARY(NXTPP_DEBUG_LIB NXT++d "${NXTPP_ROOT_DIR}/bin/win32")

INCLUDE_DIRECTORIES(${NXTPP_INCLUDE_DIR}
${PROJECT_SOURCE_DIR})

FILE(GLOB SRCS "*.c" "*.cpp" "*.cxx")
FILE(GLOB HDRS "*.h")

ADD_EXECUTABLE(nxtpp-test ${HDRS} ${SRCS})

TARGET_LINK_LIBRARIES(nxtpp-test debug ${NXTPP_DEBUG_LIB} optimized ${NXTPP_LIB})

For Anders’ C++ communication library, I found that it is just a bunch of header files so it should be even easier to use (and it does have color sensor support). More on this later.

Another interesting findings on the Wikipedia is the Python interface to the NXT, nxt-python. Installation is very easy, only a few clicks of effort and it worked right off the bat. Although it lacks documentation, the project is quite active and I foresee myself using it quite a bit.

gtest + CMake + Visual Studio

I should have posted this sooner, but all kinds of things got in the way and… Okay, that was just some lame excuse, it is because my laziness that this site has been left unattended.

I suddenly felt the urge of writing this post because the other day I saw my friend Dat was trying to get gtest to work with Visual Studio but ended up getting cryptic messages from linking errors. This has happened to me before, and I have investigated this issue.

In fact, using gtest library with CMake is fairly easy and straightforward. All you need to do is to find the corresponding library and the include path, and then link the gtest library against the executable. This works without a problem in Linux. However, it becomes a bit tricky when used in Windows (as expected?).

The main issue is the Runtime Library setting in Visual Studio:

By default, it tries to load DLL, but I was feeding it LIB file. No wonder it complains. Suppose I am building in debug mode, I need to specify gtestd.lib to be my target library and select “Multi-threaded Debug (/MTd)” as the runtime library, whereas in release mode gtest.lib needs to be specified and “Multi-threaded (/MT)” should be selected.

So, is there any workarounds to avoid this manual hassle? Sure, simply do

SET(CMAKE_CXX_FLAGS_DEBUG "/MTd")

in the CMakeLists.txt, and it will be set automatically (somehow I was under the impression that I have tested this before and it was not working, but it did work just now).

Of course, you can specifically indicate that you want a DLL to be built in gtest. Yet so far I haven’t found a way to utilize the DLL (such that it can work with /MD or /MDd), I would have to defer this problem to some C++ gurus, i.e. George Toderici (if Google Alert ever alerts him about the existence of this post), to answer.

Qt 4 + CMake + Visual Studio rules now

Thanks to Bill from Kitware Inc., who responded my previous post in a very timely manner and helped me solve the compilation issues as well as the execution error.  CMake and Visual Studio 2008 are now back in the triangle.

The compilation problem lies the source code of the Qt demo. Two other classes were declared in two of the class definition .cpp files so that either moc’ing the sources or moc’ing the headers will leave some of Q_OBJECT classes un-moc’ed, which causes the linking errors. On the other hand, qmake handles this implicitly so the project file it generates doesn’t have this problem. After moving those declarations to the header files, everything compiled nicely and quietly.

As for the debug execution problem, Bill also suggested that the commercial evaluation version of Qt 4 binary I downloaded might be built with VS 2005. If that is the case, there is no way I can execute in debug mode the program linked against the Qt 4 libraries. I was just being so naive to make the assumption that the binaries should be of no difference if QMAKESPEC is the same.

After downloading and compiling the source of Qt 4.4 beta (boy, that compilation DID take QUITE a while), everything went back to normal. I am now happily “CMaking” my projects again.

Qt 4.3.4 + CMake + Visual Studio 2008 doesn’t work

Hoping to create a nice GUI for the project I am currently working on, I downloaded the commercial version of Qt 4.3.4. It installed fine, with the option of integrating with Visual Studio disabled since the integration with VS 2008 is not officially supported yet. Trolltech has already announced to support this in the upcoming version of 4.4, though.

The demo that comes with the package looks really appealing, just like how I like it: simple, themed design and fluent animated transition, which together provide the user with maximum visual satisfaction.

Trolltech is generous enough to have included all the source code of the demo so that we can play around and figure out how to mimic those fancy effects. At first I planned to use CMake to generate the project file (.sln file in the case of Visual Studio) for the demo, in accordance with all other projects that I am working on. There are also examples of CMakeLists.txt for Qt 4 projects (here is one). Despite it seemed that everything should be easily done without any hustle, it soon turned out not to be the case this time.

First, the solution file generated by CMake just won’t compile (unless it’s a single main.cpp, in which case I got it to work) if there are other Q_OBJECT classes present. I tried both QT4_AUTOMOC and QT4_WRAP_CPP, all ended up with “error LNK2019: unresolved external symbol“:

SET(SRCS src/main.cpp src/mainwindow.cpp)
SET(HDRS include/mainwindow.h)

and either

QT4_AUTOMOC(${SRCS})
ADD_EXECUTABLE(demoGUI ${SRCS} ${HDRS})

or

QT4_WRAP_CPP(MOC_SRCS ${HDRS})
ADD_EXECUTABLE(demoGUI ${SRCS} ${HDRS} ${MOC_SRCS})

Correct me if I am doing anything wrong above. After googling a bit I figured that something is wrong with the moc’ing process, but I haven’t yet found a solution. Thus I am taking CMake out of the equation temporarily.

A nice thing about qmake that comes with the Qt package is that just like CMake it can generate project files for different platforms, with an equivalent of CMakeLists.txt, projectname.pro file. With the command

qmake -tp vc -spec win32-msvc2005

one can easily get the project file (.vcproj/.sln) for Visual Studio 2005 to use. The project compiled under VS 2008 without any error, but when running under debug mode I get either “This application has failed to start because the application configuration is incorrect” if the solution file is generated by qmake or “The application failed to initialize properly (0xc0150002)” if it is created by CMake (remember I had one single main.cpp compiled). However, the release builds executed correctly.

Again I googled for a while and found out the problem might lie in the manifest files of the Qt core dll’s. Since the QMAKESPEC is set to win32-msvc2005, the manifest files of the dll’s have VS 2005 info (Microsoft.VC80.DebugCRT) embedded. When the program compiled with VS 2008 (VC90) and linked against those dll’s tries execute, there’s a conflict in configuration. Unfortunately, none of the solutions I found worked.

Now it is quite clear that for now I cannot (at least easily) debug the Qt4 programs in VS 2008. VS 2005, on the other hand, is working as advertised both in debug and release mode. Guess I would have to stick with VS 2005 for a while before Qt 4.4 is released.

An alternative plan would be trying out the 4.4 beta to see if it is a solution, while using qmake to generate the Makefile, from which to see how the CMakeLists.txt should be written.