A question about project/solution ideology

[Michael]

Hello, I am evaluating VGDB right now. IMO it does not follow the VS  solution/project ideology. I meat I build and run the solution not a project from it. I need all dlls (projects) and exe (projects) to be deployed to the single folder to be able to run without complex path settings, project clean step shall not delete the solution folder and shall remove it’s own files only and other things like that. It would probably be a good idea to have solution level VGDB setting like remote Linux machine, output, intermediate dirs. etc. as well. I am sorry to say that the MS guys have copied your solution for VS 2017 native Linux support. I have found their solution very frustrating and started to look for a better one. It looks like it is possible to set both environments they way I like (to mimic the Windows approach completely) but I gave up with the MS variant and switched to yours. I have not tried yet setting some Linux system variables to set up the Output and Intermediate directories for all the Linux projects in the solution but I do not feel I know the right way to do this in this very moment.

You may probably want to consider a more or less complex example with 10 (ten) dlls and couple of executables in one VS solution. The purpose of the example would probably demonstrate how easily one could change common settings for the whole VS solution without any need to open and repeat these actions in tens of projects; how easily one could rebuild a concrete project in the solution (the way I do it now requires me to save prebuilt binaries of the other projects in another folder and copy them back after the Clean project command), etc. I worked with VS solutions with hundreds of Windows projects and have seen a solution with more then a thousand projects. I do believe it is possible with VGDB I just cannot figure out the right approach quickly.

[support]

Hi,

Yes, we are aware that VS2017 has basic Linux support and we are ensuring that VisualGDB has always more to offer – Powerful Linux-friendly IntelliSense, Static/Dynamic analysis, Custom actions, Profiling, Code Coverage, automatic error detection and many more features (see our Linux features page).

Our MSBuild backend is also very heavily optimized for large remotely built projects and works faster than the regular VS2017 backend.

Thanks for your suggestion. Currently editing .vgdbsettings files one-by-one could be indeed unnecessarily time-consuming, so we are experimenting with providing convenient GUI for editing multiple .vgdbsettings files at once. We will publish a tutorial showing it once this feature is available.

In the meanwhile feel free to try out our Advanced CMake subsystem – it works much better with large projects containing multiple executables and libraries as the build is orchestrated from the Linux side and CMake running on it knows exactly how to copy/remove the files. Our Advanced CMake Project Subsystem maps common CMake settings to the familiar Visual Studio GUI, making the experience similar to developing regular Windows projects.

[Michael]

> In the meanwhile feel free to try out our Advanced CMake subsystem – it works much better with
> large projects containing multiple executables and libraries as the build is orchestrated from
> the Linux side and CMake running on it knows exactly how to copy/remove the files.
1. It looks like VGDB does not support Advanced CMake subsystem for libraries. I can choose it for the Application (executable file) only.
2. I do not know CMake but it looks like it requires to store it’s build files among the sources. We cannot afford it. We can use different build systems for different purposes as far as they reside in a separate location and do not interfere with sources or official build system (that also resides in a separate location). For example my experimental MS Linux, VGDB, Intel performance tools, etc. projects reside in separate folders and I can just delete them (folders) anytime without any harm to the others.

[support]

Hi,

VisualGDB does support Advanced CMake for libraries, although you would need to first create an executable and then another library to the project (a single Advanced CMake project can contain multiple targets, as CMake system fully supports this scenario). As we are currently updating the Linux project wizard anyway, we were able to add out-of-the-box support for creating libraries to this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2070.msi. Feel free to try it out and let us know if you encounter any issues.

For CMake you don’t need to store the build files in the source directories – VisualGDB uses separate build directories for each type of build (e.g. <project dir>\VisualGDB\Debug) and you can also simply delete them.

[Author]

Posts