Needs some deeper understanding of VGDB’s VS integration

[BitFlipper]

Our project is built for both Windows and Linux. For the Linux build, VGDB is used for debugging only, not for building the project. I’m currently in the beginning stages of developing a VSPackage plugin for VS that will be better able to handle our complex build process for both Windows and Linux.

Now I noticed that VGDB uses a Makefile configuration type. In order to integrate our own project better with VS, I’m now contemplating creating our own IVsBuildableProjectCfg type. However I have a feeling this will break VGDB since it relies on the Makefile configuration type. As an experiment, I changed the Configuration Type to Utility, and while VGDB still showed up in the project’s context menu, debugging stopped working (as expected really).

Now I’m wondering if I can create our own Configuration Type but then start VGDB from within our own plugin when it is time to start debugging. Do you think this would be possible, and if so, how would I do that?

EDIT: To clarify… While I selected the Utility configuration type in my test above, if I do implement our own IVsBuildableProjectCfg type, then I won’t be using Utility, but whatever we call our project type. So in addition to Makefile, Application, Utility etc, there will be a OurOwnType under the project’s Configuration Type option. So what I’m saying is that I want to have VGDB be able to debug if OurOwnType is selected by initiating VGDB debugging via calls we make into VGDB. I believe VGDB debugging is initiated via command line so it should work in theory. But I don’t want to go down this path if anyone is aware of a reason why this just won’t work at all.

[support]

Hi,

VisualGDB uses the Makefile configuration type in order to allow VIsualStudio use IntelliSense, class diagrams and other similar features just like for normal Makefile-based projects. If you create a new project type and implement IVsBuildableProjectCfg, you should be able to launch VisualGDB for your projects by specifying the VisualGDB port supplier and debugging engine GUIDs in launch options. However in this case you might end up breaking support for IntelliSense and other similar features.

VisualGDB actually has an experimental project extension system that exposes many internal API (e.g. communicating to SSH targets) and allows writing sophisticated build and debug actions in C#. If you could provide us with an overview of your build scenario and explain why the current VisualGDB build process does not cover it, we should be able to help you develop your extension to support it properly.

[Author]

Posts