Just curious. Does anyone have any suggestions for extra c++ extensions to use in addition to the one that comes with WPILIB’s VScode package.
1 Like
Hello again.
- Disable the default VSC C++ completion (it doesn’t function great with gradlerio as you may have noticed)
- Install Clangd (this will give you better autocompletion)
- Put this script in your project root. This generates a compilation database that tells clangd how to build your project and helps it detect errors + provide completion.
- read the Readme here GitHub - theVerySharpFlat/gradleRIO_CompilationDatabase
- Build your project, run the script, open the editor, and you should get much better completion
LMK if you have any questions.
On a side note, I guess I’m obligated to tell you not to run random scripts you find on the internet. Serious consequences can arise from doing so. Maybe it’s best to ask you to read over the script before running it.
Oh yeah. The motivation for this script is that ./gradlew generateCompileCommands tends to generate broken compilation databases for some reason. Hopefully, I can find a way to get this fixed in the actual plugin. I like to avoid gradle scripting like the plague.
2 Likes
Awesome script! I got it working with some minor changes on my 2024 beta project. I submitted some PR’s to the github to fix some minor issues.
Thanks for this
A huge +1 on this, but something to beware of is that clangd has a huge stomach. At some points it may end up using all of your CPU and several gigabytes of RAM. It’llLimelight, an integrated vision coprocessor still run on less powerful systems (like my ThinkPad X220), but it may make your system unusable for a minute as it re-indexes everything.
It’s also not instant like some other languages are, so it will take a bit to get used to.
@crueter @jreneew2 Thanks for the recognition. You guys have no idea how happy this makes me!
@jreneew2 I’ll get right on your PR!
@crueter Perhaps there’s an option in Clangd to minimize memory footprint. Another thing you could try is to use gitpod for the stretches of time when you just need to get something pounded out and don’t need to deploy. I understand the pain of having a slow computer. Most of our team’s functional computers are like that. In fact, you have to move the lid back and forth on one of them until the screen lights up due to a faulty contact. Also, there might be other completion engines. Maybe Ctags?
I’ve tried really hard to get Clangd to use up less resources but nothing has done much of anything. Ive tried other completion engines and unfortunately none of them are as good as clangd is…
You could look at remote indexing, but the configuration of that seems like a pain.
gradlerio and the other WPILib gradle plugins are generally written in Java, so you can avoid gradle scripting.
The relevant portion for generating compile_commands.json is here: https://github.com/wpilibsuite/gradle-cpp-vscode/blob/main/src/main/java/edu/wpi/first/vscode/CompileCommandsConfigurationTask.java
The relevant code use some undocumented internal gradle features, so thats what I find a little annoying. Also, I’m not quite sure how to test my local version of the plugin.
The problem boils down to 2 things
- No inclusion of the -c arg (probably fixed by Don't link in compile commands by noamzaks · Pull Request #20 · wpilibsuite/gradle-cpp-vscode · GitHub)
- The lack of isystem includes makes it such that clangd cant find the default compiler includes. The work around is to specify the query-driver flag with the path to the compiler so clangd can find these paths itself.
The second is more of an invonvinience than anything and i’m currently not quite sure where in the multitudes of toolchain structures in gradles codebase that i would find that information, but the search continues! I’ve been looking into the generation of the options.txt file which includes the system include paths for some reason
Thanks for the help!
It would be helpful if you filed issues on that repo. They’re much more likely to be found in the future rather then in random CD threads.
The last comment on the -c PR raised concerns that it wouldn’t work on Windows and Linux. If you’ve tried it, it would help to comment on the PR.
I was going to try fixing it myself before opening an issue, but this seems like the best course of action. I’m pretty sure the -c option works on Linux/Windows (for the roborio/gcc toolchains anyways), but I can easily confirm and will report back on the issue.
The issue with that argument is compile commands are generated for MSVC targets and Clang targets as well, not just Gcc.
1 Like
Just now getting around to looking at this.
I’m running windows. Do I need to get Clang and LLVM first?
The script actually got integrated into gradle vscode recently, so if you add this at the top of your build.gradle in the plugins section,
id "edu.wpi.first.GradleVsCode" version "2.0.0"
You’ll be able to run ./gradlew generateCompileCommands and it will work properly.
You don’t need to separately install clang or llvm. You just need to install the clangd extension. It will prompt you to setup clang for you.
Be warned though, it does break most features of WPILIB vscode. You wont be able to debug or deploy through the GUI. (At least I haven’t figured out a workaround). You’ll have to run gradlew through the terminal to simulate and deploy
My only suggestion is to at least try the built in intellisense plugin we provide in WPILib. We really do try as hard as we can to make it work, and a lot of people don’t run into issues with it. Its generally a very small portion of people that run into issues, and when they just switch rather then try to help solve problems, it makes it impossible to try to solve any problems that help all teams.
1 Like
I think I’ll stick with the built in one for now.
The only real issues I get into is auto completion of include’s. A new file seems to take a minute before <frc/… auto loads.
I would like to say though. FRC and WPILIB have been great at helping me learn C++, both in code from the repo and help through Chief and PR’s. 
One thing a lot of people run into is they’ll create a new header, and start adding code to it before the cpp file. This actually doesn’t work right with intellisense, because it doesn’t know under what compilation contex the header is going to be compiled in. So the trick to get good header intellisense is to create the header, create the cpp file, include the header file in the cpp file, and then right click on the header file in the cpp and hit go to definition. That will open the header file in the right compilation context.
clangd doesn’t solve this either, because all it knows about are individual cpp files. The other downside of clangd is whenever you add a file, you have to rerun the gradle command to regenerate the compile commands. It won’t automatically add new files, unlike the one included by wpilib, which does.
1 Like
Thank you. I’ll try that next time this crops up.
On another note. In that I’m learning more about this language.
I learned the basics way back in 2000/2001. Then didn’t really touch the language until this year.
I have a little side question. I’ve noticed many constructors (copy constructors) be fully declared in the header file instead of the cpp file. Is this just WPILIB’s style guide or the preferred modern way to do this?