I’m trying to set up a development environment for my C++ project, including IDE integration. I’m currently flexible on which IDE to use, but am actively looking at CLion and VSCode. If it matters, I am working on a Mac and using Nix-Darwin.
So far, I have set up a shell.nix in my development directory to pull in compile dependencies, and also added a direnv .envrc file to automatically load it. This works flawlessly for CMake based builds (I can just cd into projectDir/build and invoke cmake ../ and we are good). And VSCode, with its direnv extension, does this automatically too! Perfect so far.
However, I’m wondering if/how I can extend this beauty to my IDE editor, so it can “see” the header files provided by dependencies, and thus offer real autocomplete and analysis on types they provide.
My understanding on this whole thing is vague, so please correct me if I’m wrong. But I think the compiler is able to find these files only because the clang-wrapper script adds them when the compiler is invoked. Is there a way to help the IDE see them too? If this is possible, Nix as a development platform will be amazing!
If your tooling can use a compile_commands.json file, then you generate one of those by passing -DCMAKE_EXPORT_COMPILE_COMMANDS=YES to cmake. That file will have all the right paths. I use this with ccls as an LSP server with emacs as my editor.
Is that sufficient? I think I was expecting that this file would have an actual list of directories in it, rather than just the command to run to compile. Does ccls run this and then parse the output somehow?
Anyhow, with this, ccls doesn’t appear to be working. I made a symlink from this (in the build directory) to the project’s root folder. Perhaps it is my IDE-ccls plugin though? Is there a succinct way to test ccls by itself?
a location which is also present in the output above. Yet, this location is not mentioned in the ccls output, and the VSCode is highlighting the header as “not found”.
Perhaps your CMakeLists.txt isn’t setting up the include path sufficiently. With nix-shell you don’t always need to do this because nix tells the compiler how to find things, but the IDE tooling typically does want those include paths. Admittedly, this can be tricky because nix works hard to make things work automatically, but extra tooling isn’t aware of the same magic. I actually use my own derivation for ccls and a project-aware helper. I then define a helper function in my config.nix:
I actually use my own derivation for ccls and a project-aware helper. I then define a helper function in my config.nix
Oh, wow! This is super neat!
So, given the way you designed nixAware.nix, it seems like it’s necessary to externally parse the output of clang -v. Is that “expected”? As in, not doing something along these lines simply can’t work? It is not clear to me how simply knowing the compile command could help any tool to discern these paths if they don’t parse this themselves, but in that case, why isn’t ccls doing this internally?
Anyway. I will give this a try, for sure. This looks like a great solution, and as a bonus will work with any IDE that has ccls support.
In your opinion, is this something that could be upstreamed to nixpkgs in some sense?
Also, if you might indulge me, what is the purpose of your custom ccls derivation? It seems like the magic of parsing the buildInputs locations and adding them to extraArgs is all done in your nixAware.nix. And that should work with the upstream derivation, right? (I also have a bunch of questions about the upstream derivation, but I think they’re not actually good questions, they’re just due to my inexperience with all these tools.)
I will write up a more complete presentation of my setup as a blog post if anyone would find that helpful.
One million percent yes!
Thanks so much for your help. You’ve gone way above and beyond!
It is an issue for upstream ccls, too. I don’t at the moment recall exactly how it is setup now. The author is extremely knowledgeable, and has been a huge help to me over the years; I’m sure he helped me get it all working way back when. I think that whatever mechanism ccls uses to get those paths is some interaction with libclang, but nix wraps clang rather thoroughly, making the paths ccls is able to obtain wrong for us.
My ccls derivation pre-dates the one in nixpkgs. ccls can also be a fast-moving package, which is a bit frustrating to work with in nixpkgs since one sometimes has to be fairly persistent and patient to get PRs merged. As ccls development slows down, I think it will make more sense to care more closely for what’s in nixpkgs.
I think that whatever mechanism ccls uses to get those paths is some interaction with libclang , but nix wraps clang rather thoroughly, making the paths ccls is able to obtain wrong for us.
I seeeee. Thanks for explaining. If it is useful to know, I am having success here with the upstream ccls derivation, along with your nixAware.nix.
P.S.
I don’t understand the Mac/frameworks packaging well enough yet, but I might be seeing problems with framework entries in the clang -v output, which are of the form of:
I think you’ve correctly diagnosed that problem. I haven’t tried using my ccls pieces on macOS. I can give it a shot when I have a chance, but if you get to it first and can twiddle that text parsing line to extract the right path for macOS Frameworks, please do share.