Adding Visual Studio Code code completion

Hallo,

I am new to the forum and thought I start my appearance here with a little help instruction for adding code completion for JUCE to the VS Code editor. I struggled with this and thought it might be helpful for people who are new to JUCE. Since I am on Linux and Codeblocks is the only IDE exporter option besides the make file I searched for an easy and nice alternative. For now I found it in VS Code with c++ extension installed. Here are the simple steps:

  1. Install ms-vscode.cpptools extension in VS Code:
  • Go to the Extensions Menu: View → Extensions
  • And search for “ms-vscode.cpptools” Extension
  • Install
  1. Open your make file project created via the Projucer in VS Code

  2. Add your JUCE folder path to the ms-vscode.cpptools Settings via the Command Palette:

  • Go to Command Palette: View → Command Palette
  • Type “C/C++: Edit configurations (UI)” into the Command field
  • In the IntelliSense Configurations under include path add your Juce path as a new line: /your/path/to/JUCE/**
  • that should create a hidden folder called ./vscode in your project folder which includes the file c_cpp_properties.json. This file includes the settings you did via the command palette.
    This should now enable the code completion.

I hope this helps some people. This are some easy steps and maybe not worth to mention but for me it would have been great if I had been able to find those here.

4 Likes

From my experience, VS Code is even more fun to use if you chose to use the JUCE CMake functionality instead of using Projucer for Project generation. VS Code is clever enough to find all the needed tools and can compile a CMake JUCE project after only a few clicks. This is so straightforward that personally, I would not consider using the Projucer to create a Makefile first as an intermediate step anymore. Besides that, this works the same on all operating systems – cross platform development with free tools has never been that easy :slight_smile:

7 Likes

I had a quick look into cmake functionality but since I haven’t used it before I decided to go the projucer way. I had the feeling that cmake maybe could be all I need. Will have another look into it. I imagine the FRUT github is the proper starting point? Do you have any cmake extension suggestions for vscode?

No not really, that was a community-based solution before they added built-in CMake support to JUCE. You find the documentation for it in the docs folder of the JUCE repository and some examples in the CMake subfolder of the example folder.

Of course you have to learn CMake a bit, but if you are not just generally starting with coding, learning the basics from the examples should not be too hard :slight_smile:

Allright. Thanks! I will have a look into it! :slight_smile:

cmake build works fine in the terminal but in vscode I am getting the following error while using the cmake tools extension:

CMake Error at CMakeLists.txt:40 (juce_add_plugin):Unknown CMake command "juce_add_plugin".

Since juce_add_plugin is a juce specific command it seems like JUCE isn’t added/found correctly before. How are you adding JUCE to the project?

So far only on the c++ level with the c_cpp_properties.json file.

If you take a look at the plugin example, there are two options on how to add juce:

Either via find_package or via add_subdirectory. I always used the second approach, since all my projects contain JUCE as a git submodule, so that I have full control over which exact JUCE commit each project uses

1 Like

loI. so nice and easy! I saw those two commands. but I was struggeling to find the right values/path.
I did what you suggested and simply put a whole juce source folder into the project. I think I am having all I need now with code completion debugging and building with one click in vscode.

After trying the cmake approach for a new project I have to say I find the projuicer still easier and faster to use. cmake might be much more powerfull and flexible. A cmake generator from inside projucer might be helpful for new users.

I recently started to use CPM.cmake

It basically a cmake file you copy/paste into your repo and invoke with one line:

CPMAddPackage(
        NAME JUCE
        GITHUB_REPOSITORY juce-framework/JUCE
        GIT_TAG origin/develop)

It will fetch JUCE from git while configuring the project (so doesn’t require an additional git command or external tool), but unlike git submodules it can also be configured to share the same version of JUCE you have locally, while still making sure you will pull a valid version from git if you didn’t.

Here’s an example:

3 Likes

Oh looks nice. Much to learn about cmake and its possibilities on my side.

Has anyone managed to get VSCode to play nicely with JUCE modules?

With everything set up properly as described above, VSCode still fails to recognise JUCE’s unity-build style where module files are included in the top-level header, and don’t include their own dependencies.

For example, opening juce_ValueTree.h in VSCode shows that all the JUCE symbols are undefined (e.g. Identifier, UndoManager, etc.).

Anyone know how to config that properly? Searching for unity build on Google just gives a whole bunch of results about using the Unity Engine…

1 Like

I’m struggling with the same thing too.
For me, the symbols in header files resolve fine, but resolving the symbols in the implementation files fails.
I also tried using the compile_commands.json, but (obviously) the source files, e.g. juce_ValueTree.cpp isn’t found in the compile commands, since the file that is actually passed to the compiler is juce_data_structures.cpp.

I tried all relevant options for the VS Code C++ plugin (e.g. forced include sounded promising), but i didn’t succeed…

However I’ve noticed that the resolving works if i include the module header in the .cpp which might be a solution for own modules, but of course doesn’t work for the original juce modules.

@reuk is there something that can be done here?

I think this simply comes down to the fact that while JUCE uses a unity-build method, its .cpp files don’t include header files. From the few examples I could find, it’s still typical to include the required headers in a .cpp - when you merge the translation units, the included headers are still only processed once.

I think the only way to get VSCode (or rather intellisense, which I think is the thing that’s actually tripping up) to work properly with unity-builds would be to have all source files include their required headers.

As you say, this is an easy fix for our own modules, but would require a lot of work to go through the entire JUCE codebase to fix this for JUCE modules.

1 Like

Yep, I agree. It sounds like to get this working, we’d need to go through and update all of the JUCE module sources with the correct includes. This is something I’ve been considering on and off for a while, but it’s a change I don’t want to make without appropriate tooling to check that the includes are correct and minimal. I think such tools do exist, but getting them set up and integrated into CI will take some time. At the moment we have quite a few higher-priority issues to look at, so I don’t see this happening in the short term.

3 Likes

Thanks for the clarification.
Would adding the appropriate includes also mean that JUCE will move away from the unity build scheme?

That would be an incredibly disruptive change, so it would be very unlikely to happen.

No need for compilicated toolings, as your compiler is enough.
Here’s how I’ve done it in my own modules and it works very well with VSCode and other IDEs:

Create a test project that links to a single module and then:

  1. Remove all the includes from the module header (juce_core.h, etc)
  2. Everything now will stop compiling.
  3. Start by slowly adding includes to each cpp until everything compiles again
  4. Only add to the main header file the headers that aren’t included in any other headers.

At this point verifying that the JUCE demos/unit tests compile should be enough to let you know you’ve done this correctly.