CMake support

[AssertionBit]

Check for existing issues

• Completed

Is your feature request related to a problem?

I think, that CMake language and as the build tool is not related to language requests. CMake language is separate thing, but the build system is other.

Previous mention of this topic: #5269.
Also related: #5437, zed-industries/extensions#135

Related issue just got mention of CMake support, but primary just asks for plugins support. For now Zed is not parsing make file, not loading caches provided by make and so on. For now C/C++/ObjC/... projects are working on file based project structure.

All build tools for C languages (cmake, ninja, mason) are not working for now.

Describe the solution you'd like

I would like to see project loading, like CLion have. JetBrains added support for it in their primary IntelliJ IDEA and in CLion. VSCode also has that feature with CMake plugin. Both of them could be good references for quite good project indexing.

For the UI, I think, that we need in commands in command pallet like building target, reloading project and so on. They could appear in case of CMake project detected and loaded successfully. For developing support, there is one helpful option: cmake caches. In them cmake contains tons of useful information about structure, loading and so on.

I see two ways of solution.

Native support of CMake

This way requires more time and code for achieving result, but it will provide cross-platform support for C/C++ projects (CMake is only one native way of building projects on windows, according to official documentation of Microsoft).

So this way probably will cause the two steps to do:

1. Wrap cmake terminal utillity in some sort of interface.
2. Calling it when project detected.
3. Redirecting caches to cmake-build-debug folder, like CLion does (with cmake -B . -S cmake-build-debug).

After that, You will have folder, that contains structured information about all targets, languages, errors and so on. I look through cargo's and there is no of them, doing this job.

Shadow calling of CMake

Cmake is just preprocessor to other things (ninja, make, mason, xcode). Probably, You may add support for Make projects and then just invoke cmake with generating Makefile (that appears on top of cache folder). This way maybe more useful, because make projects are more widely used and automatically adding support to tons of other languages.

For developers

I am working on monorepo tool that must support CMake build system tool. Because of that, I was need in some sort of parser for it too. I tried to find some sort of solution to these problem for half a year, but there is no tool for getting information from CMake projects.

Just making this note is not useful. For developers I may provide some sort of beta-parser of cmake projects in rust, c or cpp, which may help during Your work in development. Or more detailed documentation about cache folder structure. Like I mentioned in #5104 issue, the way that You propably may use is single interface for build tools.

If applicable, add mockups / screenshots to help present your vision of the feature

Example UI of working with CMake from command pallet

[gracicot]

Note that with CMake support, CMake presets usually offers the best integration with editors. If the CMake plugin support for generating a base config or adds a UI to configure CMake, it should be done through CMakePreset.json/CMakeUserPresets.json

[jansol]

Dropping these here as well since this issue seems to also be tagged for cmake language support and a good experience editing the CMake project files themselves is the more important part of this for me personally.
LSP: https://github.com/Decodetalkers/neocmakelsp
tree-sitter: https://github.com/uyha/tree-sitter-cmake

[xbz-24]

zed editor called suitable for c++ development without even supporting syntax coloring for .cmake files?

[jansol]

when is it going to have cmake support zed editor wtf????

As soon as someone implements it. Wanna volunteer?

I actually had a rough plugin wired up to provide syntax highlighting + neocmakelsp but it broke when the plugin interface was refactored last week. I might find time to fix that plugin and push it to the extension repo eventually but I have no interest in developing a configuration GUI as that does not really have any value to me. There is currently also no way for extensions to define their own GUI so that is going to have to wait a while longer anyway.

That said the syntax highlighting + LSP plugin is very straightforward to replicate based on e.g. the uiua language plugin, in case someone else wants to take a stab before I get to it.

[xbz-24]

Im not even joking this is how cmakelists.txt looks like.

there is no need for complex features like LSP.

just syntax coloring could be a great addition, I already had the same issue with xcode, but in there I just enabled c++ coloring and it "did the trick", they also offer no cmake LSP but just syntax coloring. . .

(what I meant https://stackoverflow.com/questions/63455480/xcode-11-and-cmake-syntax-highlighting)

[jansol]

You can do the same trick in Zed

[xbz-24]

how

[xbz-24]

when is it going to have cmake support zed editor wtf????

As soon as someone implements it. Wanna volunteer?

I actually had a rough plugin wired up to provide syntax highlighting + neocmakelsp but it broke when the plugin interface was refactored last week. I might find time to fix that plugin and push it to the extension repo eventually but I have no interest in developing a configuration GUI as that does not really have any value to me. There is currently also no way for extensions to define their own GUI so that is going to have to wait a while longer anyway.

That said the syntax highlighting + LSP plugin is very straightforward to replicate based on e.g. the uiua language plugin, in case someone else wants to take a stab before I get to it.

please let me know if you manage to complete your task

[mrnugget]

how

language selector: toggle and then chosing c++.

[xbz-24]

how do I get to the language selector thingy

[mrnugget]

cmd-shift-p or click on the file type down here:

[AssertionBit]

how

language selector: toggle and then chosing c++.

I this this is not a solution. It is a trick. Maybe I will start working on plugin for CMake and general C/C++ support.

[jansol]

and general C/C++ support

There already is syntax highlighting and LSP (clangd) support for C and C++. If you mean build/debug support then I hope you aren't in a hurry because you'll find that Zed is still lacking integration APIs for implementing those.

[mrnugget]

I think a first step could be to add CMakeLists.txt to these two lists:

zed/crates/languages/src/c/config.toml

Line 3 in c0d1171

path_suffixes = ["c"]

zed/crates/languages/src/cpp/config.toml

Line 3 in c0d1171

path_suffixes = ["cc", "hh", "cpp", "h", "hpp", "cxx", "hxx", "c++", "ipp"]

That's also how we handle highlighting Gemfiles as Ruby files, for example:

zed/crates/languages/src/ruby/config.toml

Line 5 in c0d1171

"Gemfile",

But obviously the downside of that is that it treats CMakeLists.txt as C/CPP files, even though they are not.

The better solution would be to use https://github.com/uyha/tree-sitter-cmake and add a language extension to that.

[xbz-24]

is someone fixing this shit or not

[xbz-24]

Redirecting caches to cmake-build-debug folder, like CLion does (with cmake -B . -S cmake-build-debug).

I wanted to add you probably meant

cmake -B cmake-build-debug -S .
-B flag is for build, -S flag is for source
but the point got across please let me know if someone is fixing this shit or not

[AssertionBit]

and general C/C++ support

There already is syntax highlighting and LSP (clangd) support for C and C++. If you mean build/debug support then I hope you aren't in a hurry because you'll find that Zed is still lacking integration APIs for implementing those.

I read through all API and will be working on providing general support. I know that there is only syntax highlighting and LSP, but (I hope) that in future this issue will be fixed ASAP

[AssertionBit]

I think a first step could be to add CMakeLists.txt to these two lists:

zed/crates/languages/src/c/config.toml

Line 3 in c0d1171

path_suffixes = ["c"]

zed/crates/languages/src/cpp/config.toml

Line 3 in c0d1171

path_suffixes = ["cc", "hh", "cpp", "h", "hpp", "cxx", "hxx", "c++", "ipp"]

That's also how we handle highlighting Gemfiles as Ruby files, for example:

zed/crates/languages/src/ruby/config.toml

Line 5 in c0d1171

"Gemfile",

But obviously the downside of that is that it treats CMakeLists.txt as C/CPP files, even though they are not.

The better solution would be to use https://github.com/uyha/tree-sitter-cmake and add a language extension to that.

I don't think so. Tree-Sitter is just general parser and doesn't provides required cabilities (like other C/C++ tools) does. So there is a lot of work to be done

[k0tran]

Hi, I maintain zed cmake extension, which has tree sitter and LSP (https://github.com/k0tran/zed_neocmake). It also has README with short instructions on integrating clangd (C++ LSP) and creating cmake task (shortcut for building your project). It has enough features at least for me. I would like a way to add template of CMake C++ task into the extension/editor interface so you don't need to open github page every time.

On the first iterations of the extension I put path_suffixes = ["CMakeLists.txt"] and it worked then. But recently it broke and now Zed considers CMakeLists.txt a Plain Text file. I siffed through Zed source code and found this line (

zed/assets/settings/default.json

Line 838 in 17b9d19

"Plain Text": ["txt"],

). I propose (if it is possible) to somehow exclude CMakeLists.txt from Plain Text mask. Or add new line for CMake. Maybe there other parts of source code that can be tweaked to make this work again.

I also would like an addition here

zed/crates/extensions_ui/src/extension_suggest.rs

Line 16 in 17b9d19

const SUGGESTIONS_BY_EXTENSION_ID: &[(&str, &[&str])] = &[

If it's required I can make two separate issues for those problems

[mrnugget]

@k0tran yeah, I think specific issues such as "CMakeLists.txt is considered a text file" would be good to have.

[k0tran]

@k0tran yeah, I think specific issues such as "CMakeLists.txt is considered a text file" would be good to have.

Opened one issue
#20291
And one pull request
#20292