[support]

Hi,

This looks like VisualGDB gets an incorrect path for the intermediate directory. It’s hard to say what is going on based on this log alone, so we would advise the following steps for diagnosing this:

• Narrow the scope for just one project created from scratch. This will help track the issues down.
• Try setting the project output directory to the path you want directly (via VS Project Properties). Does this break the build? If yes, please compare the .msbuild-mak files for working and non-working scenarios.
• Try setting it via a property sheet file like you did before. If this breaks the build, again try comparing the .msbuild-mak files for the 2 scenarios and double-check all paths.
• If it works for 1 project, try referencing the same property sheet from another project. If it breaks the build, please try comparing the 2 .vcxproj files to understand which of the settings causes the conflict.

[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.

[support]

Hi,

Yes, the Keil importer might have skipped a macro during the import process if it was defined in a non-typical way. The easiest workaround would be to add it manually via VisualGDB Project Properties -> MSBuild Properties -> Preprocessor Macros.

[support]

Hi,

Sorry, we don’t sell any JTAG cables. The only advice we could give is to ask around make communities/forums if anyone else managed to find a ready cable anywhere.

[support]

Hi,

Thanks for clarifying it. Normally it should be equivalent to the one VisualGDB provides (the vector names are taken from the ST examples and should match the other components), so it should be OK to use the one from VisualGDB. If you believe the startup files are different, please let us know and we will try to suggest a workaround.

[support]

Hi,

OK, thanks for reporting this. We have updated the regex loading logic so that it will use the regexes from RegularExpressions.xml for the fields not set in BuildMessageTemplates.xml. This will be included in the upcoming v5.4 Preview 1.

[support]

Hi,

Thanks, this sounds like a way to improve usability, however unfortunately CMake doesn’t expose this information in the data that VisualGDB uses in the Advanced CMake subsystem. We will look into patching CMake to make it report this structure, but we cannot promise that it will work until we investigate it in more detail.

[support]

Hi,

The custom rules defined for Windows projects might not work out-of-the-box for Linux. Please try following our Qt MSBuild tutorial for a detailed example of defining rules for running custom tools on Linux. If you have any further questions, please feel free to share more details about your current setup (e.g. what exact rules you are using) and we will try to help you.

[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.

[support]

Hi,

Thanks for reporting this. We will try to improve the navigation bar experience for large fonts in one of the next VisualGDB releases.

[support]

Hi,

No problem, we have managed to find the previous topic you created about linker scripts: https://sysprogs.com/w/forums/topic/custom-template-exception/. If you have any further questions, feel free to post in any of the topics and we will be happy to answer them.

Regarding the startup file, do you mean the system init file, or the startup file with vectors and libc initialization?

[support]

Hi,

Thanks for the update. This should indeed work, however the project-specific templates should work as well. If anyone can reproduce the problem with the broken per-project regexes and attach a repro, we should be able to investigate and fix it.

[support]

Hi,

Sorry, that would not work currently, as the ESP-IDF is not directly compatible with MSBuild (it depends on hardcoded file order and a few other constraints). We realize that ESP-IDF is frequently updated and are working on an experimental project subsystem similar to the Advanced CMake Project Subsystem that will be able to map native ESP-IDF projects directly into Visual Studio GUI, instead of importing ESP-IDF sources to MSBuild.

We expect to release a preview build with this subsystem in the next 2-3 weeks.

[support]

Hi,

Unfortunately this is also a known limitation of the ESP32 debugging that comes from the Xtensa toolchain (the ESP32 devices are not based on the ARM core; this helps reducing the price, however makes impossible to use the mature ecosystem of the ARM tools). Please feel free to look through the post covering other limitations of the ESP32 toolchain and known workarounds: https://sysprogs.com/w/limitations-of-the-esp32-debugging/

The recommended workaround is to always have a top-level wrapper function in every thread.

[support]

Hi,

Thanks, yes, if you could send us a repro case, we should be able to fix it easily.

BTW, please try deleting the ImplicitCompilerFlags.xml file and reopening the project – unless you do that, VisualGDB will reuse the incorrect flags cached by the previous version.

[Author]

Posts