IDE & Debugging

ViewTouch contributors uniformly pefer CMake, a free software, cross-platform family of tools designed to build, test and package software. CMake controls the software compilation process using simple platform and compiler independent configuration files, and generate native makefiles and workspaces that can be used in the compiler environment of one's choice.

A very prolific contributor, NeroBurner, recommends the QT Creator IDE and the SourceTrail, cross-platform source explorer for C/C++ as development tools. QT Creator can be configured to work with SourceTrail by adding the QT Creator plugin to SourceTrail. Anyone not wanting to use GCC can, of course, use Clang. QT offers very helpful documentation for setting up the debugger of one's choice.

Nicholas Turnbull uses Eclipse and offers this tip; "I've found that of all the possible IDEs for reviewing and debugging ViewTouch, Eclipse C++ Development Toolkit turns out to be ideal. I'd been laboriously recompiling it via the command line and eventually it just got too much of a drag. By adding the -g flag to the cmake build file, setting Eclipse's build command to "make install" from the /build directory and pointing the Run command to /usr/viewtouch/bin, it's possible to actually both debug and install a live system interactively with everything in the proper directories. The graphical interface to gdb in Eclipse allows the precise object fields to be inspected and the events traced, which is a huge help."

With HiDef displays going for as little as $50-$60 everyone who is going to view/learn ViewTouch code can quite effortlessly set up two HiDef displays so one display is running the ViewTouch GUI and a second display is running one's preferred IDE and debugger, providing a view of the code execution simultaneously with the GUI. I realize that some will say, well duh, to this, but I also realize that others are simply not doing this because they have simply never learned to use a debugger! I have often asked myself why anyone who regards oneself as a programmer would settle for accepting such a handicap. If it's a question of how to do it then let's open an issue and provide a howto for such a setup, OK? Here are some relevant comments about the topic from Garret Polderman.

Sergii Pylypenko reminds that everyone should also, obviously, be making use of Valgrind. Qt Creator integrates Valgrind code analysis tools for detecting memory leaks and profiling function execution. I would mention cppcheck, too.