VisualGDB still using CMake server mode?

[curtis.hendrix]

Environment: Visual Studio 2019 with VisualGDB 6.0R6 (Build 5262).

I’m trying to import an existing CMake project (similar to this guide https://visualgdb.com/tutorials/arm/cmake/import/), and I’m running into this error.

CMake Error: CMake server mode has been removed in favor of the file-api.

No reply via CMake server API. Restarting CMake in file mode...

System.Exception: CMake server exited with code 1
at xp2.b(Object b, EventArgs a)

The project is configured to use CMake located within C:\Users\<username>\AppData\Local\VisualGDB\CMake.  Running

C:\Users\<username>\AppData\Local\VisualGDB\CMake\bin\cmake.exe --version

outputs “cmake version 3.20.3-dirty”

CMake did generate the Ninja build files and manually invoking Ninja successfully built the firmware. With my (very limited) knowledge of how CMake and IDEs integrate, this looks like a potential issue with VisualGDB?

[support]

Hi,

Unless the API is forced to the deprecated server mode (via Tools->Options->VisualGDB->CMake->API for querying CMake state), VisualGDB will automatically detect the API for each project.

It looks like it does attempt it here:

Restarting CMake in file mode...

Normally, the log should show what is happening next (VisualGDB trying to launch it in the file mode and possibly hitting some other error). If there isn’t anything obvious, please try the steps below:

1. Make sure it works with new project created from scratch on the same machine using the same CMake/toolchain.
2. Make a copy of the configuration log (it will contain similar lines for trying the server mode).
3. Get a log for the broken project and try comparing it against the working one. It should easily point out what is different.

If nothing helps, feel free to attach both logs here, and we can recheck.

[curtis.hendrix]

I think I might be onto something.  I created a new project with a different firmware project that uses the nRF52833.  I was able to select the nRF52833 during project creation during the “Device Selection” step.  I ran into some issues with the CMakePresets.json, but I switched the project config’s “Store build settings in” to “Project File” and got everything to work fine.

However, the problem project is based on the PAC5532, which does not show up in the “Device Selection”.  I selected “Specify flags manually” and left everything as default, and then imported the CMakelists.txt and toolchain definition files.

I’ve been able to reproduce this twice.  The project with the PAC5532 will always fail with

No reply via CMake file API. Restarting CMake in server mode...
CMake Error: CMake server mode has been removed in favor of the file-api.

The project wit hthe nRF52833 will work (with a little fiddling).

[curtis.hendrix]

That may not be it.  On the good project, CMake will detect the tool chain (see good config.txt).  However, on the bad project, CMake jumps straight to

-- Configuring done (0.2s)
-- Generating done (0.0s)
-- Build files have been written to <location>

(see bad config.txt)
I can reproduce this and fix it on a command line.  If I copy-paste the “Running CMake” command into a command line, same result.  However, changing the cmake.exe  to a non-VisualGDB version results in CMake correctly detecting the toolchain.

Attachments:

You must be logged in to view attached files.

[curtis.hendrix]

Also with the nRF52833 project, I did convert it to standalone under “Embedded Project” so it better mimicked the PAC5532 project.

[support]

Thanks, this explains it. Something in the build scripts of a particular nRFConnect target triggers an internal error in a particular CMake version, so it silently crashes and VisualGDB doesn’t recognize it as normal error (since there is no error message). It could be related to this particular CMake version, or to some of our patches.

We would normally update the CMake shipped with VisualGDB in a few months after we are done prototyping a rather large feature planned for the next version. It should port all fixes from the mainline CMake, and is likely to resolve this issues as well.

If switching to the normal CMake until than works for you (or if you can narrow down a specific construct causing this), that should be the easiest way to handle it. If not, we can build a debug version of CMake so that you could capture a minidump and we could patch it, but it could involve several back-and-forth iterations.

[curtis.hendrix]

The nRF52833 project uses the nRF 5 SDK, not the nRF Connect SDK, and it’s working fine.  The problem project is firmware for a PAC5532.  Is there a way to manually set the CMake executable that VisualGDB will use when it loads a CMake project?

[support]

Sure, you can set Tools->Options->VisualGDB->CMake->Use pre-built CMake for Local Builds to false, and then change VisualGDB Project Properties -> CMake Build Settings -> CMake Command.

[curtis.hendrix]

I figured out what the problem was by very carefully comparing the outputs of the good project and the problem project.

The problem was there were some CMake files left over from a previous attempt in my project root directory, rather than the /build/VisualGDB/Debug sub directory.  Files like CMakeCache.txt, cmake_install.cmake, build.ninja, .ninja_log, and .ninja_deps.

When the project was loaded (I think), the Advanced VisualGDB Project Output was outputting

-- Configuring done
-- Generating done
-- Build files have been written to: C:/Repos/<repo root>/

right after the “Running CMake” long command.

Once I deleted everything that I knew was not needed from the repo root, that log became

-- Configuring done
-- Generating done
-- Build files have been written to: C:/Repos/<repo root>/build/VisualGDB/debug

And it appears to be working.

[Author]

Posts