சுதர்சன் சாந்தியப்பன்

    When I was using KDevelop 4.2 for debugging a process, I got perplexed having the inferior application closing down whenever I was setting a breakpoint on the fly.  On the contrary, the breakpoints there were setup before the start of the inferior application, things behave as expected.  With little bit of digging, it is found that whenever a new breakpoint is setup or removed (Toggle Breakpoint), kDevelop inherently issues a SIGINT to the inferior application, which in turn stops the application from debugging.  To handle this problem, setup a signal handler for SIGINT, to consume the Interrupt signal (Ctrl+C, Ctrl+Break).  But once the debugging is over, don’t forget to reset the SIGINT handler.

While working with KDevelop 4.2, I was quite disturbed by suddenly freezing of editing window. In the sense, the opening file is uneditable, “find” strings does not work and literally kDevelop becomes unusable. I had to restart kDevelop 4.2 to resume editing the code. I believed that kDevelop is going into Vi mode and was trying to undo that. But that’s not the problem.

When kDevelop loses focus, somehow the editing capability is disabled temporarily. When you switch context a couple of time by Alt-Tab and land is kDevelop again, the editing capability is resumed. I don’t know whether this is a bug, but context-switching has been my breather for now.

    KDevelop4 has adopted CMake build system over AutoMake build system of KDevelop3. So, projects that are hosted on KDevelop3 environment cannot work seamlessly on KDevelop4 environment, which makes is practically impossible to migrate to KDevelop4 which is far superior in terms of functionality and usability.  Moreover, all latest Ubuntu flavors (Linux Mint 10 x64) give KDevelop4 as the default IDE under KDE.

    CMake is more powerful build system than Automake.  A very nice comparison of CMake and Autotools is found here.  The reason for KDevelop moving over to CMake is described in this article.  CMake also provides some scripts that help one to migrate the KDevelop3 projects to KDevelop4 CMake projects.  Once such script is am2cmake, which is written in Ruby.  If you run this script from the root directory of the KDevelop3 projects folder, the ruby script automatically reads Makefile.am and traverses through the directory to convert Makefile.am to CMakeLists.txt.  But there is a small bug in that.  While running the script on StaticLib directory, one might get the following error message:

converting Makefile.am
Makefile.am PROBLEM: target not found:  libanalyzer_server_a_SOURCES = Admin.cpp Admin.hpp AnalyzerC.cpp AnalyzerC.h     AnalyzerS.cpp AnalyzerS.h CmdInfo.cpp CmdInfo.hpp Config.cpp Config.hpp     Manager.cpp Manager.hpp ModelTask.cpp ModelTask.hpp

The original Makefile.am that was converted is:

INCLUDES = -I$(top_srcdir)/config -I$(top_srcdir)/idls -I$(top_srcdir)/libs \
    -I$(top_srcdir)/libs/bgtLicensing -I$(top_srcdir)/libs/hmm -I$(STL_ROOT)/stlport -I$(DEV_ROOT)/idls/src \
    -I$(TAO_ROOT)/orbsvcs/orbsvcs -I$(TAO_ROOT)/orbsvcs -I$(TAO_ROOT) -I$(ACE_ROOT)
METASOURCES = AUTO
AM_CFLAGS = -Wall -pthread -D_Linux_ -D__STL_CLASS_PARTIAL_SPECIALIZATION -m64
AM_CXXFLAGS = -Wall -pthread -D_Linux_ -D__STL_CLASS_PARTIAL_SPECIALIZATION -m64
lib_LIBRARIES = libanalyzer_server.a
libanalyzer_server_a_SOURCES = Admin.cpp Admin.hpp AnalyzerC.cpp AnalyzerC.h\
    AnalyzerS.cpp AnalyzerS.h CmdInfo.cpp CmdInfo.hpp Config.cpp Config.hpp\
    Manager.cpp Manager.hpp ModelTask.cpp ModelTask.hpp

Basically, while translating the Makefiles for static libs, am2cmake script does not know how to extract the target name from the Makefile.  By applying the below patch the problem was fixed.  Basically, a rule is added to addTarget function to handle lib_LIBRARIES = line from Makefile.am

336a337,339
>       elsif line =~ /^\s*lib_LIBRARIES\s*=\s*(\S+.*)/
>          targets=$1
>          type=StaticLib

[Updated 04/07/2011: A more or less completed script is available here for converting non KDE projects, which should transform all the projects from kdev3  (native c++ projects that are non-kde) to CMakeLists.txt format. Use ruby am2cmake.rb --no-kde to run the script.]