Add automatic kit scanning functionality by drook207 · Pull Request #351 · Civitasv/cmake-tools.nvim

drook207 · 2025-11-01T13:54:14Z

Summary

This PR adds automatic CMake kit detection and scanning capabilities to
cmake-tools.nvim, making it easier to get started without manually
configuring compiler kits.

Automatically scans PATH for GCC and Clang compiler pairs
Detects compiler versions and finds matching C++ compilers
Discovers linkers (lld/ld) and toolchain files from environment
Saves discovered kits to ~/.config/cmake-tools/cmake-kits.json
Falls back to automatic scanning when no kits file exists
Adds CMakeScanForKits user command for manual scanning

Changes

New module: lua/cmake-tools/scanner.lua - Core kit scanning
implementation with:
- Compiler detection (GCC/Clang with version parsing)
- Linker and toolchain file discovery
- Custom JSON encoder for saving kits
- PATH scanning and file utilities
Enhanced workflow: Automatic kit scanning when cmake-kits.json
doesn't exist
User command: CMakeScanForKits for manual kit discovery
Default config: Set cmake_kits_path to ~/.config/cmake-tools/ by
default

Test plan

Test automatic kit scanning on first run (no kits file)
Test manual CMakeScanForKits command
Verify GCC detection and version parsing
Verify Clang detection and version parsing
Check that generated kits file is valid JSON
Ensure linker and toolchain detection works correctly
Test with multiple compilers in PATH

lceWolf

I like the idea, it replicates vscode's automatic kit detection 👍

Tilde was not exapanded correctly, that results in creating the kits file in creating the whole path in $PWD

- Add a test for kit scanning - Add a test that checks if the file is present and if the kits could be registered

Backmerge Main

- Complete reimplementation of the scanner functionality using nvim's internal functions and a more generic approach. - Add possibility to detect cross platform compiler - Make the scanner more extensible - Add unit tests for the new functions

drook207 · 2026-04-11T08:20:03Z

Hi guys, sorry that it took so long to continue, but as I got back to it i decided to start right from the beginning. I now use the nvim api for all the detection functions and I try to make it as extensible as possible. For now we are able to detect clang and gcc compiler on linux systems (And cross compilation compilers as well). I would suggest to do another PR for the WIndows MSVC and MinGW functionality.

drook207 · 2026-04-12T05:56:52Z

And one further question. Should we regenerate the cmake kits file entirely when the user command is triggered or should we append only new kits to the file?

lceWolf · 2026-04-14T17:06:57Z

  -- if exists cmake-kits.json, kit is used to set
  -- environmental variables and args.
-  local kits_config = kits.parse(const.cmake_kits_path, config.cwd)
+  local kits_config = kits.parse(const.cmake_config_path, config.cwd)


I think this has to stay const.cmake_kits_path, right?

If so, do we need const.cmake_config_path at all?

The parse function expects not only a path but also the filename for the cmake kits. But I agree to leave the const.cmake_kits_path nil.
The questions is should we add the kits filename to the const table and concat the config path and the filename ?

lceWolf · 2026-04-14T17:09:53Z

  cmake.register_autocmd()
  cmake.register_autocmd_provided_by_users()
  cmake.register_scratch_buffer(config.executor.name, config.runner.name)
+  if not vim.uv.fs_stat(const.cmake_kits_path) then


maye we should add an option like we did for the presets to enable kit usage?

I think it might be worth keeping const.cmake_kits_path = nil as default and not change existing behaviour 🤔

lceWolf · 2026-04-14T17:12:28Z

  cmake.register_autocmd_provided_by_users()
  cmake.register_scratch_buffer(config.executor.name, config.runner.name)
+  if not vim.uv.fs_stat(const.cmake_kits_path) then
+    scanner.scan_for_kits()


this is a synchronous which can block the ui on startup. I think it is work running async, right?

lceWolf · 2026-04-14T17:14:29Z

+end
+
+local function get_path_executables()
+  local path_dirs = vim.split(vim.env.PATH or "", ":", { plain = true })


this will break on windows

lceWolf · 2026-04-14T17:51:38Z

+  local seen = {}
+  local chains = {}
+
+  for exe in pairs(executables) do


I think this filtering could be moved to the point of searching the paths variable

I don't get what you mean, sorry. Could you maybe give a further explenation?

lceWolf · 2026-04-14T17:59:56Z

+  return {
+    c = (prefix or "") .. c_name,
+    cxx = (prefix or "") .. companions.cxx,
+    linker = (prefix or "") .. companions.linker,


I think this is actually wrong for lld. See It is always a cross-linker, meaning that it always supports all the above targets however it was built. In fact, we don’t provide a build-time option to enable/disable each target. This should make it easy to use our linker as part of a cross-compile toolchain.

Ok thanks again for the docs. So should we maybe take out the linker detection complety? Becaus if I get it correct, vscode's cmake-tools does not add the linker at all. It is again a manual step.

lceWolf · 2026-04-14T18:12:54Z

+      kit.compilers.C = get_executable_path(tc.c)
+
+      if has_cxx then
+        kit.compilers.CXX = get_executable_path(tc.cxx)


I think this can be called unconditionally. vim.fn.exepath should yield the correct result

lceWolf · 2026-04-14T18:23:02Z

Hi guys, sorry that it took so long to continue, but as I got back to it i decided to start right from the beginning. I now use the nvim api for all the detection functions and I try to make it as extensible as possible. For now we are able to detect clang and gcc compiler on linux systems (And cross compilation compilers as well). I would suggest to do another PR for the WIndows MSVC and MinGW functionality.

No worries. Thats quite the topic to tackle and you are moving in a good direction! :)

I would suggest to do another PR for the WIndows MSVC and MinGW functionality.

Maybe I missed a detail, but I think the PR might break existing setups on windows since the PATH parsing does only work for Unix systems

lceWolf · 2026-04-14T18:24:10Z

And one further question. Should we regenerate the cmake kits file entirely when the user command is triggered or should we append only new kits to the file?

How does the VS Code extension handle it?
I think stale kits should be removed

Refactor: Change cmake kits path back to nil

fix: remove duplicated code line

drook207 · 2026-04-16T19:56:38Z

And one further question. Should we regenerate the cmake kits file entirely when the user command is triggered or should we append only new kits to the file?

How does the VS Code extension handle it? I think stale kits should be removed

No they add and update only.
docs

I'm with you, stale kits should be cleaned if one triggers scan for kit manually

drook207 · 2026-04-16T19:58:42Z

Hi guys, sorry that it took so long to continue, but as I got back to it i decided to start right from the beginning. I now use the nvim api for all the detection functions and I try to make it as extensible as possible. For now we are able to detect clang and gcc compiler on linux systems (And cross compilation compilers as well). I would suggest to do another PR for the WIndows MSVC and MinGW functionality.

No worries. Thats quite the topic to tackle and you are moving in a good direction! :)

I would suggest to do another PR for the WIndows MSVC and MinGW functionality.

Maybe I missed a detail, but I think the PR might break existing setups on windows since the PATH parsing does only work for Unix systems

Yes you were right, did not see that. I fixed the path separator so the plugin should continue to work on windows. But I will ensure that tomorrow with my work PO

drook207 added 7 commits October 25, 2025 23:19

Add basic implementation for kit scanner

822b317

Fix call to make directory

09afee7

Add global config dir for kit file

206038a

Fix version parsing

e4f2c2d

Add linker and toolchain to global kit file

52f1efc

Add automatic kit scanning

4481b50

Add user command for kit scanning

e58c87d

lceWolf reviewed Nov 12, 2025

View reviewed changes

drook207 and others added 14 commits November 12, 2025 21:15

Use path from const table

a1bc307

Use vim mkdir builtin

adeb9e5

Fix: Config path for cmake kits

e0bd683

Tilde was not exapanded correctly, that results in creating the kits file in creating the whole path in $PWD

Feature: Use vim builtin json functions

a6602cd

Feature: Add tests

b71824b

- Add a test for kit scanning - Add a test that checks if the file is present and if the kits could be registered

Merge pull request #1 from Civitasv/master

49f717d

Backmerge Main

Merge branch 'master' into feature-add-kit-scanner

6f259b5

Fix: Make regex more simple

3022b5c

Fix: Use built in functions

e547e0d

Refactor: Improve kit detection

e44aae1

Merge branch 'Civitasv:master' into master

dd64e52

Refactor: Reimplement scanner function

9bf4e1b

- Complete reimplementation of the scanner functionality using nvim's internal functions and a more generic approach. - Add possibility to detect cross platform compiler - Make the scanner more extensible - Add unit tests for the new functions

Merge branch 'master' into feature-add-kit-scanner

8d06f2d

Refactor: Remove Debug logs

ea837cc

drook207 marked this pull request as ready for review April 11, 2026 08:20

drook207 added 4 commits April 11, 2026 20:38

feat(constants): Add cmake-tools config path

8975ae3

fix(scanner): Create config dir if not exists

12d1018

fix(scanner):Move initial scan for kits to setup

9f1c58b

fix(autocommands): Add missing implementation for scan for kits

47b60a8

lceWolf reviewed Apr 14, 2026

View reviewed changes

drook207 added 7 commits April 16, 2026 20:40

refactor: Use stdpath(config) for path expansion

e3723fe

Refactor: Change cmake kits path back to nil

refactor: Reduce noise while scanning for kits

9d46a1e

refactor: name loop variable more meaningfull

75c8279

refactor: Remove unused files

684d9eb

fix: make path separator system dependant

2898fd0

refactor: return boolean as the function name suggests

02a80c1

refactor: move executable variable to global scope

b83a051

fix: remove duplicated code line

refactor: remove unnecessary conditions

757cd4a

Conversation

drook207 commented Nov 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Test plan

Uh oh!

lceWolf left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

drook207 commented Apr 11, 2026

Uh oh!

drook207 commented Apr 12, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lceWolf commented Apr 14, 2026

Uh oh!

lceWolf commented Apr 14, 2026

Uh oh!

drook207 commented Apr 16, 2026

Uh oh!

drook207 commented Apr 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

drook207 commented Nov 1, 2025 •

edited

Loading