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

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

[Author]

Posts