[support]

Hi,

Thank you for your feedback. We are committed to making VisualGDB better than other options and are constantly working on improving the usability and adding more features. However in order to keep focusing on making our products better, we are not able to provide any free project-specific customization work, although we are happy to show examples of various VisualGDB settings and explain how they work.

If you ever decide to give VisualGDB another try, feel free to get back to us and we will be happy to answer your questions.

[support]

Hi,

Sure, we can do it as a part of our short-term consulting program. Please feel free to contact our sales to get a quote.

[support]

Hi,

Thanks, we’ll try to add an option for that to v5.4.

[support]

Hi,

This looks like you are using GNU Make; please try creating an MSBuild-based project instead – it should have all arguments escaped properly. We are also working on an experimental ESP-IDF-based project subsystem that will eliminate the need to use a separate BSP and will be able to display the ESP-IDF project structure directly in Solution Explorer. Once we release a preview build with this feature (1-2 weeks from now), we will recommend using it as the primary way of building ESP32 projects.

Regarding esptool.py, VisualGDB can do this automatically if you select “UART (program only)” in the debug method. VisualGDB can’t debug ESP32 devices over UART yet, however it will automatically invoke esptool.py to program your firmware.

[support]

Hi,

Thanks for confirming this. Just another quick question – are the flags from CMAKE_CXX_COMPILER_ARG1 mentioned anywhere else in the JSON file? If not, could you please share a repro project so that we could investigate this and submit a patch to CMake?

[support]

Hi,

No problem, the topic will remain open and if any other user would like to volunteer and look into this, we obviously won’t stop them. We just wanted to post a quick update that we won’t be able to investigate this under our usual support terms unless you extend your support period. Sorry if we caused any confusion.

[support]

Hi,

Looks like your support period has expired. In order to keep on receiving technical support, please renew your license.

[support]

Hi,

Thanks for the detailed description. Please try our latest build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2075.msi

If the problem persists, please share the ENTIRE build log (you can do find-and-replace to switch out meaningful project/file names with random names, but we will need to see the order of internal VisualGDB messages in order to understand what is going on).

As another quick check, please try running Ninja manually via SSH and confirm that it produces the output consistently and doesn’t freeze.

[support]

Hi,

It looks like your are using an external build of GoogleTest. VisualGDB can only recognize unit tests if they are built with a patched version of GoogleTest that contains VisualGDB-specific code. Please try creating a regular MSBuild-based test project, locate the files automatically added by VisualGDB and ensure you add the same files to your CMake-based project. This should get VisualGDB to recognize the tests as if it was a normal project created through the wizard.

[support]

Hi,

Yes, please see the Raw Terminal page of VisualGDB Project Properties.

[support]

Hi,

There should be a workaround for this, however it depends on the project type you are using. Is it an MSBuild project, plain GNU Make project, or CMake project? If it’s a Make project, was it created with VisualGDB wizard or imported from an existing Makefile?

[support]

Hi,

VisualGDB uses the flags reported by CMake via the server interface. Could you check the CodeModel.json file in your build directory (it will be fairly large, so using an online JSON formatter might help understand it). The relevant part should look like this:

"fileGroups":[
 {"compileFlags":"-g -fPIC ",<...>,"sources":["LinuxProject.cpp"]}

Do the compileFlags for your .cpp file include the flags from CMAKE_CXX_COMPILER_ARG1 ?

[support]

Hi,

No problem, we have double-checked the setup steps to support this and will provide the detailed instructions below. Please follow the instructions below first to check that all rules get processed properly, and then change the rules to use your actual build tool:

1. Create 2 empty files in the project directory: test1.x and test2.x
2. Add them to your .vcxproj file using the <CustomFile> element:

    <ItemGroup>
    <CustomFile Include="test1.x" />
    <CustomFile Include="test2.x" />
    </ItemGroup>

3. Add a new target that will “compile” them (in this example we will just change the extension to .c):

    <Target Name="CompileCustomFiles">
      <Exec Command="copy /y %(CustomFile.Identity) @(CustomFile->'%(filename).c')" Condition="@(CustomFile) != ''"/>
      <ItemGroup>
        <ClCompile Include="@(CustomFile->'%(filename).c')"/>
      </ItemGroup>
    </Target>

4. Finally register the new target with VisualGDB:

    <PropertyGroup>
    <ComputeCompileInputsTargets>$(ComputeCompileInputsTargets);CompileCustomFiles</ComputeCompileInputsTargets>
    </PropertyGroup>

When you build the project, you should see VisualGDB copy the 2 files and then send the resulting files along with your sources to Linux before they are built:

1>------ Build started: Project: LinuxProject, Configuration: Debug VisualGDB ------
1> 1 file(s) copied.
1> 1 file(s) copied.
1>VisualGDB: Sending 3 updated source files to build machine...
1>VisualGDB: Run "make -f "VisualGDB/Debug/LinuxProject.msbuild-mak" --no-print-directory" in directory "/tmp/VisualGDB/e/projects/temp/LinuxProject" on testuser@kubuntu17vm (SSH)
1>LinuxProject.cpp
1>Linking VisualGDB/Debug/LinuxProject...
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Let us know if you have any further questions and we will be happy to answer them.

[support]

Hi,

Thanks for reporting this, looks like our bug. Please try updating your BSP via VisualGDB Package Manager. This should automatically install a fix for this.

[support]

Hi,

No problem, we have added an option to remove the default startup file from the project. Please update your BSP via VisualGDB Package Manager and use the new option on the first page of the VisualGDB Project Properties.

[Author]

Posts