Table of Contents
This chapter generally outlines WinGDB integration with standard Visual Studio projects and solutions. The integration is comprised from several different aspects.
WinGDB adds its own settings to the standard Visual Studio ones. These settings are stored in project files. There are two kinds of settings, with regard to where are they stored:
WinGDB does not force the classification of options into these two categories. Instead, it allows you to choose for each option, whether it has to be stored temporarily or persistently. Typically, debugger options are better to be stored temporarily, as this storage is not shared between users through the source control and they can specify different debugging machines and logins. On the other hand, the build and makefile settings are better to be stored permanently, as they are always the same for each user.
User and persistent settings are connected by inheritance relation. User option inherits its default value from corresponding persistent option value. That means, if you do not set value explicitly on user level, it will be same as on persistent level. Alternatively you can override the value on the user level.
This section contains a detailed description of the settings management.
For platforms involving development on remote machine, there are two logical locations of the source files. The sources must be visible on the local machine for editing and simultaneously on the remote machine for building. This makes necessary to use two hierarchies of paths, in the local and remote filesystem. These two hierarchies correspond to each other.
In the project mode, WinGDB maintains path mappings between directories on local and remote machine. It gives the following advantages:
For each mapping, WinGDB also remembers its synchronization mode. You can choose whether there is a Samba sharing set up already and no synchronizing is needed, or there is no sharing and WinGDB has to copy files on change. In the latter case, the files are automatically copied with SCP or SFTP protocol. The process is transparent and you can work in similar manner as with Samba share.
WinGDB always stores mappings in the suo file (as user-level settings) because they are inherently per-user.
The mappings are described in more detail in this section.
WinGDB is also aware of currently selected solution configuration. All settings are store per configuration, so that you can configure WinGDB differently (or even selectively turn it off) for each configuration.
You can find more information on configuration management in this section.
There are several actions which are typically performed on projects in Visual Studio. The Debug action start debugging session. The Build, Rebuild and Clean actions are related to building the project. The Deploy action transfers build artifacts to the target system and prepares them for running.
WinGDB offers its own counterparts of these actions. They are configurable through the properties mechanism described above. These actions can be scoped to the selected project (with or without dependent projects), startup project or the whole solution. WinGDB provides menu options for each type and scope of action. WinGDB-specific commands can be bound to keystrokes in Visual Studio with standard customization dialog.
The options for build-related actions are described here.
Another posibility is to use the command interception feature provided by WinGDB. In that mode, WinGDB substitutes standard Visual Studio commands with its own ones, so that you can just press the same key as for regular Visual Studio project to start WinGDB action (e.g. F5 for debugging). This feature is optional and set per project and configuration. This way, you can turn it on only for remote platform configurations. This section shows how to enable or disable the interception feature.
For the following options accessible from the WinGDB main menu: Start debugging, Launch process, Attach to process and Examine core, settings are taken from the Startup project (the one marked bold in the Solution Explorer).
Project actions described above can be also performed on the whole solution level. WinGDB also supports this scenario. You can supply commands to build the whole solution. Also the interception feature may be separately enabled or disabled for entire solution, affecting the solution-level commands.
You can access the solution-level properties by right-clicking on the solution node in Solution Explorer and choosing Properties from WinGDB menu.
You can use Visual Studio macros in all WinGDB properties which accept paths or other strings. Visual Studio macros are special variables (like $(ConfigurationName) or $(ProjectDir)) which are substituted with concrete values depending on actual project settings. All macros known by Visual Studio are supported. You can view list of them by choosing standard Visual Studio Properties option on a project, then clicking on "..." button for some property and then Macros button. Macros are supported on project or solution level only (not single-file).
In addition to Visual Studio macros, you can use your own variables. They are used in similar way as macro variables. You can find more information on that topic in this section.
When you add or remove source files, these changes must be reflected into the target build system. Manual updating is tedious, therefore WinGDB provides automated mechanism for this task. Currently it supports GNU make. The makefiles can be either generated from scratch, or selectively updated to change only the source files list. This feature is described in more detail here.
You can set the dependencies for WinGDB-enabled projects as usual in Visual Studio, with Project/Project dependencies menu option.
WinGDB works with standard Visual Studio IntelliSense features. You can find more information on configuring projects for IntelliSense in this section.
Table of Contents