Forum Replies Created
-
Posts
-
Hi,
The AdditionalIncludeDirectories variable exists on the MSBuild level and is not generally passed to the VisualGDB level (to make things more complicated, it is not a global MSBuild variable, but a property of each individual ClCompile item).
To work around it, you would need to create a custom MSBuild target, translate %(ClCompile.AdditionalIncludeDirectories) into a global variable (just placing <PropertyGroup> inside the custom target might work) and then use the <Exec> task to launch the custom tool. The rest of the variables you mentioned are available both on VisualGDB and MSBuild level, so they will work in this scenario as well.
An easier alternative would be to create a basic property sheet defining the include directories (see the stm32.props file created by VisualGDB for embedded STM32 projects), referencing it from your project and parsing its contents from the custom tool. This will avoid complex MSBuild scripting and will still avoid having multiple redundant definitions of the include directories.
Sorry, we have not explicitly tested VisualGDB with Jenkins yet. Producing the .trx file with the /vsoutput option and then using the regular MSTest plugin should normally work. If not, please share the details and we will try to help you configure it.
Thanks for reporting this. We have fixed it in our development branch and will include in the next VisualKernel update.
Hi,
It looks like the linux-source-4.19 package got corrupt. Please try removing it via apt-get remove, deleting the /usr/src/linux* folders and letting VisualKernel reinstall it.
Yes, starting from VisualGDB 5.x, you can import the STM32CubeIDE projects directly using the STM32CubeIDE import plugin.
Sorry, could you please post a screenshot of the entire VS window as well. It really shows a lot of important information about the state of the Clang engine (see this explanation). Otherwise, it’s virtually impossible to guess what is going on.
Second of all, does the problem happen with GPIO_PIN_Reset? If yes, please try the following:
- Try simplifying the expression as much as possible. E.g. “int x = GPIO_PIN_Reset”. Does this still reproduce the problem? If not, is there any specific change between the repro code and the “int x” example that changes the behavior?
- If the simple case still triggers the problem, does moving right after the preamble (i.e. block of #include<>’s) change anything?
- What happens if you add another enum (not just another value to an existing enum) near the place where GPIO_PIN_Reset is defined? Will it trigger the problem as well?
- If yes, what if you move the newly added enum to the source file that triggers the problem (try putting it before and after the #include<> block)?
Hi,
We would advise creating a VisualKernel project for the kernel itself (see this tutorial). First of all, this will allow building and installing the kernel directly from Visual Studio.
Second of all, all you would need to do when creating a new kernel module, is to select “My Kernel is built with VisualKernel” and point it to the Kernel project file. This will automatically handle build paths, versions and source file mappings (see this tutorial).
Thanks for confirming your license key.
The “Exclude from build” setting works out-of-the-box for MSBuild-based projects only. In order to achieve the same effect with GNU Make-based projects, we can advise one of the 2 workarounds:
- You can manually use the $(filter-out …) expression combined with ifeq($(CONFIG), DEBUG) to filter out specific files from the source file list (see how this is handled for STARTUPFILES). VisualGDB will preserve your changes to the Makefile, although they won’t be synchronized with the VS-level “exclude from project” setting.
- Alternatively, simply surround the code in your source files with #ifdef DEBUG (or any other macro used in your project to distinguish debug/release configurations).
Most likely, the *.xml is not mentioned in the copied file masks. If you could share a screenshot of your settings, we should be able check this and help you find the cause.
The return code of 0 means that the there was no critical error preventing VisualGDB from launching the tests. You can find out the specific tests that succeeded/failed by analyzing the report file generated by either /output or /vsoutput option (see this thread).
If this doesn’t help, please let us know what exactly you are trying to accomplish and we will try to suggest the best setup for it.
Hi,
Although VisualGDB cannot directly generate a Junit-compatible output, it can be configured to generate the outputs in the Visual Studio/MSTest test report format.
You can do this via the following command line
VisualGDB.exe /runtests <...> /vsoutput:<output file>
As both JUnit and MSTest test report formats are very popular, there are various open-source translators between them, so we would advise simply running one of them after VisualGDB returns.
It looks like you are not using the ESP-IDF component GUI. Please ensure you use the Advanced ESP-IDF project wizard as suggested by VisualGDB and shown in this tutorial.
Unfortunately we are not able to guarantee that every possible combination of Arduino targets and libraries will work. Please consider posting on the Arduino forums for further support.
