master .sln project with many .vcxproj, is this supported

Sysprogs forums Forums VisualGDB master .sln project with many .vcxproj, is this supported

This topic contains 1 reply, has 2 voices, and was last updated by  support 2 months, 1 week ago.

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #25614

    bycrom
    Participant

    Hello,

    We have a historic windows code base which is shipped as an executable along with our built .dll files. The project is configured using a .sln file with many sub-projects .vcxproj files that build the .dll library’s.

    In Visual Studio it looks something like included project_ui.jpg

    The file structure on disk for this looks something like included file_structure.jpg

    Is this supported by VisualGDB in the manner I would hope. Meaning I will be able to create VisualGDB projects for each .dll (.vcxproj) and the main executable with the following abilities?

    1. In Visual Studio when the master project is set to as the start up project and built, all the subprojects are remotely built as is defined in projects build order with the final executable built along with libraries remotely.
    2. In Visual Studio if I right click on a subproject and choose “build subproject” this would invoke a remote build of only that library? See enclosed build_subproject.jpg. This is important in that it will help me move through the porting process easier since I can pick specific libraries to build/fix and move through dependencies systematically.

    Thank you in advance.

    Attachments:
    You must be logged in to view attached files.
    #25624

    support
    Keymaster

    Hi,

    Yes, VisualGDB fully supports this layout. If you are planning to continue having the Windows builds, we recommend using the Project->Add Linux Configuration command to add a VisualGDB configuration to all of the projects (if you have multiple project files, we would advise comparing the .vcxproj file before and after and scripting the necessary changes).

    If you are no longer interested in maintaining the Windows builds, we would advise creating an Advanced CMake project. It fully supports multiple targets as well has an advantage of sharing common project properties (e.g. build machine, custom steps) between all targets built within the project.

    If you have any further questions, please don’t hesitate to get back to us and we will be happy to provide more details.

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.