Troubleshooting in the IDE

The following table answers some IDE questions you might encounter:

Table 1. Troubleshooting issues in the IDE
Question Answer
Why is nothing displaying in the IDE? Since one of the goals of the IDE is to simplify and automate work for developers, it needs to be told what to do. There are two settings (per project and global default settings) that are important:
  • The binary parser setting lets IDE tools (like the Debug Launcher) filter binary code from source code. When you see the Binary Parser task running in the progress bar, that's the background thread iterating over the project content; its attempting to determine which files are binaries and which aren't. When you select Search (vs Browse), that's what provides the (virtual) content for the binaries folder in the Project Explorer view, as well as the content for the Debug Launcher file selection dialog . If you don't see anything in the Project Explorer view or the Debug Launcher, then the binary search has not come across anything yet and/or is not complete, or the binary parser is mis-configured (it should be QNX ELF).
  • The debugger setting. There are many debuggers available for use in different situations, and while all of the QNX configurations should have an appropriate default setting. However, if your debugger is not behaving as expected (particularly with local or gdb remote target configurations), ensure that the debugger is set as a QNX gdb type.
Do I need to convert my build process to match an IDE project? For nearly every type of existing code with a build process, you'll want to choose the standard C (or C++) Make Project type because it simply calls out to an external build program to build the source (typically, it's make, but it could be JAM, ANT, dmake, or any other builder.)

If you start a project from scratch, using a QNX Projects allows you to build for multiple processors (referred to as variants, including OS types) with a single build based on the QNX recursive make framework (however, they won't port well to other systems.)

Managed make Projects provide a full IDE graphical control and configuration, and they take advantage of the Eclipse framework (i.e. incremental compiles, links, and so on).

If you never intend to run your build from the IDE, only use the standard make type to identify the source as C/C++ source, and to identify the binary types.

Do I need to convert my build to a QNX Momentics style project to use the IDE? The IDE wants you to narrow down the scope of what it needs to know about source, binaries, and so on. Therefore, you'll need to create a project associated with your specific requirements (source/binaries) and this project is in turn associated with a workspace; however, this project doesn't have to be in the workspace; it can be anywhere you want.
The following are all valid locations:
  • The source can reside in a project that is in the workspace, which is the default location when you create a new project, when you import source into the IDE using File > Import from the filesystem (which can perform a copy, but it's not necessary to do so), or by using a version control plugin, such as SVN.
  • The source exists somewhere in the filesystem, and you want to overlay a project at that location. You can achieve this by creating a project and changing the default location from the workspace to the location of the source.
  • The source is somewhere in the filesystem, but you don't want to create any metadata files in that particular location. In this case, you want to create an empty project (either in the workspace, or another location). Next, you want to create a folder in that project and make the folder location point to the source in the filesystem using the >>Advanced section of the Import dialog. This is similar to a symlink in Unix, but this link only exists in the IDE workspace.
Related concepts
Starting the IDE
Using the workbench
Using the QNX help system
Creating a project
The IDE project model
Supported project types in the IDE
Scenarios for creating a project for the first time
Sharing projects
Building a single project
Setting build properties for a project
Building from the command line
Configuring automated builds
Related tasks
Checking out a partial source tree
Checking out existing projects
Example #1: the Makefile is in the root
Example #2: the Makefile isn't in the root
Example #3: a link for the output directory
Example #4: there are links for everything