microsoft / vscode-cmake-tools

CMake integration in Visual Studio Code
https://marketplace.visualstudio.com/items?itemName=vector-of-bool.cmake-tools
MIT License
1.44k stars 432 forks source link

Multi-project configuration #1120

Open bobbrow opened 4 years ago

bobbrow commented 4 years ago

I develop embedded software for Zephyr RTOS as well. The compile_commands.json works great for the project directory. However, it doesn't work so well for the underlying RTOS directory. I get errors such as:

"i2c_sam0.c" not found in "/Users/.../build/compile_commands.json". 'includePath' from c_cpp_properties.json will be used for this file instead.

This particular file (i2c_sam0.c) is a Zephyr driver and not part of the application. When working with your application, it is often helpful to view the drivers used by the application (and other components of the RTOS such as kernel, sub systems, etc) and to have intellisense properly parse these files when you open them. Moreover, I debug these drivers and it is essential to be able to properly parse them.

Originally posted by @sslupsky in https://github.com/microsoft/vscode-cmake-tools/issues/915#issuecomment-599125576

bobbrow commented 4 years ago

How is your workspace set up in vscode? Are there two folders with code in them? (e.g. one for the drive and one for the application). I'm wondering if using VS Code's multiple folder support + configuring with cpptools' Configuration Provider API will work better than compile_commands.json for you.

sslupsky commented 4 years ago

I do have VSCode setup with multiple folders using my own workspace. I added my application folder and the Zephyr folder to the workspace.

One folder contains the Zephyr source from here: https://github.com/zephyrproject-rtos/zephyr

And the other is the application project folder that contains the source for the application. For example, the blinky sample copied to a separate folder from here: https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/basic/blinky

The way Zephyr works is the kernel is compiled and linked with the application into one binary. This helps to eliminate redundant and unused code that would be an issue for constrained devices. The Zephyr project uses West to generate a number of intermediate files that are used to build the binary including kernel configuration options and device tree options. The generated files are contained in the application build folder.

I stumbled across the "Configuration Provider API" yesterday with respect to the CMake Tools extension. That did not seem to make a difference for me yet as I could not figure out a way to tell CMake Tools about multiple directories. Though, as mentioned above, my workspace does include both folders.

If I inform CMake to export the compile commands by adding the following line to the CMakeLists.txt at the root of the application folder:

set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

CMake exports the compile commands for the application targets but does not include the Zephyr library targets. The Zephyr library targets (driver libs, kernel lib, sub system libs, etc) are not included in the compile commands.

Earlier today I determined a way to inform the Zephyr build process to export the additional compile commands by manually editing the CMakeList.txt files in each of the sub folders that contain the code that is compiled to the Zephyr libs. For my build environment these folders include:

arch/arm boards drivers kernel soc subsys

When I inspected the compile_commands.json after these changes, there was additional build information for the components compiled into the Zephyr libs.

This configuration works better and generally I do not have squiggles with my includes that are part of the compile commands. However, there still appears to be a problem.

Here is a copy of my compile_commands.json: (This isn't the entire file, just a snippet from the beginning.)

[
{
  "directory": "/Users/stevenslupsky/Documents/source/blinky/build",
  "command": "/usr/local/bin/arm-none-eabi-gcc -DBUILD_VERSION=v2.1.0-rc1-182-gb54ee41160d6 -DKERNEL -D_FORTIFY_SOURCE=2 -D__PROGRAM_START -D__ZEPHYR__=1 -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include/drivers -Izephyr/include/generated -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/soc/arm/atmel_sam0/samd21 -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/drivers -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/soc/arm/atmel_sam0/common/. -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/ext/lib/fnmatch/. -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/ext/hal/cmsis/Core/Include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/subsys/usb -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/hal/atmel/asf/sam0/include/samd21 -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/debug/segger/rtt -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/fs/littlefs -isystem /Users/stevenslupsky/Documents/source/zephyrproject/zephyr/lib/libc/minimal/include -isystem /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/8.2.1/include -isystem /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/8.2.1/include-fixed    -Og -imacros/Users/stevenslupsky/Documents/source/blinky/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mthumb -mcpu=cortex-m0plus -imacros/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=/Users/stevenslupsky/Documents/source/blinky=CMAKE_SOURCE_DIR -fmacro-prefix-map=/Users/stevenslupsky/Documents/source/zephyrproject/zephyr=ZEPHYR_BASE -ffunction-sections -fdata-sections -mabi=aapcs -march=armv6s-m -std=c99 -nostdinc -o CMakeFiles/app.dir/src/main.c.obj   -c /Users/stevenslupsky/Documents/source/blinky/src/main.c",
  "file": "/Users/stevenslupsky/Documents/source/blinky/src/main.c"
},

{
  "directory": "/Users/stevenslupsky/Documents/source/blinky/build",
  "command": "/usr/local/bin/arm-none-eabi-gcc -DBUILD_VERSION=v2.1.0-rc1-182-gb54ee41160d6 -DKERNEL -D_FORTIFY_SOURCE=2 -D__PROGRAM_START -D__ZEPHYR__=1 -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include/drivers -Izephyr/include/generated -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/soc/arm/atmel_sam0/samd21 -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/drivers -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/soc/arm/atmel_sam0/common/. -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/ext/lib/fnmatch/. -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/ext/hal/cmsis/Core/Include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/subsys/usb -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/hal/atmel/asf/sam0/include/samd21 -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/debug/segger/rtt -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/fs/littlefs -isystem /Users/stevenslupsky/Documents/source/zephyrproject/zephyr/lib/libc/minimal/include -isystem /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/8.2.1/include -isystem /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/8.2.1/include-fixed    -Og -imacros/Users/stevenslupsky/Documents/source/blinky/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mthumb -mcpu=cortex-m0plus -imacros/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=/Users/stevenslupsky/Documents/source/blinky=CMAKE_SOURCE_DIR -fmacro-prefix-map=/Users/stevenslupsky/Documents/source/zephyrproject/zephyr=ZEPHYR_BASE -ffunction-sections -fdata-sections -mabi=aapcs -march=armv6s-m -std=c99 -nostdinc -o CMakeFiles/app.dir/src/led.c.obj   -c /Users/stevenslupsky/Documents/source/blinky/src/led.c",
  "file": "/Users/stevenslupsky/Documents/source/blinky/src/led.c"
},

{
  "directory": "/Users/stevenslupsky/Documents/source/blinky/build",
  "command": "/usr/local/bin/arm-none-eabi-gcc -DBUILD_VERSION=v2.1.0-rc1-182-gb54ee41160d6 -DKERNEL -D_FORTIFY_SOURCE=2 -D__PROGRAM_START -D__ZEPHYR_SUPERVISOR__ -D__ZEPHYR__=1 -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/kernel/include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/arch/arm/include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include/drivers -Izephyr/include/generated -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/soc/arm/atmel_sam0/samd21 -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/drivers -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/soc/arm/atmel_sam0/common/. -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/ext/lib/fnmatch/. -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/ext/hal/cmsis/Core/Include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/subsys/usb -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/hal/atmel/asf/sam0/include/samd21 -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/debug/segger/rtt -isystem /Users/stevenslupsky/Documents/source/zephyrproject/zephyr/lib/libc/minimal/include -isystem /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/8.2.1/include -isystem /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/8.2.1/include-fixed    -Og -imacros/Users/stevenslupsky/Documents/source/blinky/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mthumb -mcpu=cortex-m0plus -imacros/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=/Users/stevenslupsky/Documents/source/blinky=CMAKE_SOURCE_DIR -fmacro-prefix-map=/Users/stevenslupsky/Documents/source/zephyrproject/zephyr=ZEPHYR_BASE -ffunction-sections -fdata-sections -mabi=aapcs -march=armv6s-m -std=c99 -nostdinc -o zephyr/arch/common/CMakeFiles/arch__common.dir/isr_tables.c.obj   -c /Users/stevenslupsky/Documents/source/zephyrproject/zephyr/arch/common/isr_tables.c",
  "file": "/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/arch/common/isr_tables.c"
},

{
  "directory": "/Users/stevenslupsky/Documents/source/blinky/build",
  "command": "/usr/local/bin/arm-none-eabi-gcc -DBUILD_VERSION=v2.1.0-rc1-182-gb54ee41160d6 -DKERNEL -D_FORTIFY_SOURCE=2 -D__PROGRAM_START -D__ZEPHYR_SUPERVISOR__ -D__ZEPHYR__=1 -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/kernel/include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/arch/arm/include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include/drivers -Izephyr/include/generated -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/soc/arm/atmel_sam0/samd21 -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/drivers -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/soc/arm/atmel_sam0/common/. -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/ext/lib/fnmatch/. -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/ext/hal/cmsis/Core/Include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/subsys/usb -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/hal/atmel/asf/sam0/include/samd21 -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/debug/segger/rtt -isystem /Users/stevenslupsky/Documents/source/zephyrproject/zephyr/lib/libc/minimal/include -isystem /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/8.2.1/include -isystem /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/8.2.1/include-fixed    -Og -imacros/Users/stevenslupsky/Documents/source/blinky/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mthumb -mcpu=cortex-m0plus -imacros/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=/Users/stevenslupsky/Documents/source/blinky=CMAKE_SOURCE_DIR -fmacro-prefix-map=/Users/stevenslupsky/Documents/source/zephyrproject/zephyr=ZEPHYR_BASE -ffunction-sections -fdata-sections -mabi=aapcs -march=armv6s-m -std=c99 -nostdinc -o zephyr/arch/common/CMakeFiles/arch__common.dir/sw_isr_common.c.obj   -c /Users/stevenslupsky/Documents/source/zephyrproject/zephyr/arch/common/sw_isr_common.c",
  "file": "/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/arch/common/sw_isr_common.c"
},

For some reason I am getting multiple file matches for some of the Zephyr includes. For instance, . That is, if I #include in my main.c (or in one of the Zephyr source files) and then right click and select 'Go To Definition', I will get a list of 76 soc.h files. When this happens it quite often causes undesirable issues with the linting (reports errors incorrectly) because it more often than not picks the wrong file.

So for some reason the compile commands are not sufficient to resolve the path to the correct version of soc.h and I have not been able to determine why. Other includes are affected as well (for example errno.h, device.h, init.h) though not the degree that soc.h is.

bobbrow commented 4 years ago

Sorry for the delay on this. I ran into some problems trying to get the workspace configured (Zephyr's walkthrough didn't work for me), and I haven't had time to dig in deep and troubleshoot it yet.

sslupsky commented 4 years ago

Np, it took me a little time to get Zephyr up and running. I am not sure I fully understand it yet but I am learning.

I did a little more digging but haven't been able to figure out what the problem is. I did not have this problem when I was using manually specified the includes, forced includes and defines in c_cpp_properties.json.

sslupsky commented 4 years ago

When I manually include the CMAKE_EXPORT_COMPILE_COMMANDS in the CMakeLists.txt files in the Zephyr tree as mentioned above, most of them appear in the compile_commands.json file. However, there are still a few that are not being included.

For instance, I compile for the samd21 mcu and configure to use the rtc as the timer and the watchdog. For some reason, the targets for these (sam0_rtc_timer.c and wdt_sam0.c) do not appear in the compile_commands.json file. So, there are a small number of Zephyr files that have intellisense errors. This is a CMake issue though and I've posted an issue on the Zephyr GitHub page to try to resolve how to propagate the setting properly to the entire build.

I still have not determined the cause of the multiple file matches described earlier, so that is still outstanding.

bobbrow commented 4 years ago

My problem is that I was unable to get CMake to successfully configure the sample project yet. This is the error I get with blinky. Maybe you can help. I set some variables in cmake.environment to get some stuff to work ($ZEPHYR_BASE, $BOARD, etc), but I don't know what a dtc is or how to update it.

-- Application: /home/bob/git/zephyr/samples/basic/blinky
[cmake] -- Zephyr version: 2.2.99
[cmake] -- Board: stm32f0_disco
[cmake] CMake Error at /home/bob/git/zephyr/cmake/extensions.cmake:1457 (message):
[cmake]   Assertion failed: The detected dtc version is unsupported.
[cmake] 
[cmake]       The version was found to be 1.4.5                                   
[cmake]       But the minimum supported version is 1.4.6                        
[cmake]       See https://docs.zephyrproject.org/latest/getting_started/                     
[cmake]       for how to use the SDK's dtc alongside a custom toolchain.
[cmake] Call Stack (most recent call first):
[cmake]   /home/bob/git/zephyr/cmake/host-tools.cmake:69 (assert)
[cmake]   /home/bob/git/zephyr/cmake/app/boilerplate.cmake:445 (include)
[cmake]   CMakeLists.txt:4 (include)
[cmake] 
sslupsky commented 4 years ago

I found this discussion that might help resolve the dtc version issue: https://github.com/zephyrproject-rtos/zephyr/issues/17543

From the discuss there I think you might need to verify that the ZEPHYR_SDK_INSTALL_DIR environment variable is properly set. Also, delete the build directory so that anything cached from a previous build with the incorrect sdk path is deleted.

I can confirm that setting the CMAKE_EXPORT_COMPILE_COMMANDS from the command line works better than using the setting in the CMakeLists.txt file(s). Now all the zephyr components are included in the compile_commands.json file. I did so by adding a define to the west build command:

west build -b <board> <app directory> -- -DCMAKE_EXPORT_COMPILE_COMMANDS=1
sslupsky commented 4 years ago

I believe I have made progress on this issue. I believe intellisense is falling back to a default configuration. I am using a multi root workspace. It appears that the c_cpp_properties for each folder in the multi root workspace must be configured individually. The configuration selected for the zephyr tree folder specified a compile_commands.json file instead of the configurationProvider. For some reason, I was not getting an error message about a missing file. I switched the configuration to use the CMake-Tools configurationProvider. Now, intellisense linting is working.

I am uncertain if the problem was resolved because I specified the CMAKE_EXPORT_COMPILE_COMMANDS build option on the command line or if it was because of a typo the in the compile_commands.json line of the selected configuration.

After fixing the problem with the CMAKE_EXPORT_COMPILE_COMMANDS and restarting VSCode, an error message came up indicating a missing compile_commands.json file which prompted me to switch the configuration.

Note that "Go to Definition" for soc.h still shows 76 definitions. So the include resolution still appears to not work correctly. However, the linting appears to be ok now as I have no errors reported and all the Zephyr defines in my sam0_rtc_timer.c file appear to be resolved.

I have simplified my c_cpp_properties files for the app project and the zephyr folders as follows:

{
    "configurations": [
        {
            "name": "Mac",
            "includePath": [],
            "forcedInclude": [],
            "defines": [],
            "compilerPath": "/usr/local/bin/arm-none-eabi-gcc",
            "cStandard": "c11",
            "cppStandard": "c++17",
            "intelliSenseMode": "gcc-x64"
        },
        {
            "name": "CMake-Tools",
            "configurationProvider": "vector-of-bool.cmake-tools",
            "forcedInclude": [
                "${workspaceFolder}/.vscode/c_cpp_undef.h"
            ]
        }
    ],
    "version": 4
}

Screen Shot 2020-03-20 at 11 38 59 AM

sslupsky commented 4 years ago

One observation is that the error message that indicates an error with the configuration would benefit with additional information about what exactly it is referring to. Here is a screen shot: Screen Shot 2020-03-20 at 12 52 50 PM What is not clear is which configuration it is referring to. Does the message refer to the configuration in the .code-workspace file or one of the configurations in the c_cpp_properties.json file?

I copied a project directory and renamed it. I have opened the copy and I get the message in the screen shot above. I'm trying to run down where the problem is and it is not obvious.

sslupsky commented 4 years ago

Mysteriously the copied project is linting now. I do not know why. I reloaded the window a couple times and now the configurationProvider is working.

sslupsky commented 4 years ago

I vaguely recall reading something a while ago about the CMake-Tools extension and the configurationProvider ... that sometimes there can take a while before CMake-Tools informs c_cpp that it is providing a configuration. I do not recall exactly where I saw it though. I believe it was in the CMake-Tools issues. ... ahh, I found it here: https://github.com/microsoft/vscode-cmake-tools/issues/928#issuecomment-555643669 What did you mean by "sometimes this takes a while"?

bobbrow commented 4 years ago

I mean that the "Configure" step can take a while depending on the project. And CMake Tools doesn't register itself as a provider until a successful configure happens. There is a setting to tell CMake Tools to immediately configure when the extension activates. I recommend setting it if you use the configuration provider.

"cmake.configureOnOpen": true,
sslupsky commented 4 years ago

Ok, thanks. I will set that. Just to confirm, this setting goes into the settings section of the .code-workspace file?

bobbrow commented 4 years ago

Yes, or put it in the "User" settings so that it applies to all of your projects.

sslupsky commented 4 years ago

I think I have a better understanding of what is going on.

Resolving the location of a header file can result in multiple paths. I have noticed this happens when there are headers that have no corresponding ".c" target in compile_commands.json. For instance, #include in main.c.

I think perhaps the c/cpp extension appears to be attempting to find a "kernel.c" target. Since "kernel.c" is not a target in compile_commands.json, the c/cpp extension defaults to another search process (default include paths) and comes up with multiple paths.

It seems to me that c/cpp should have used the "main.c" target in compile_commands.json?

sslupsky commented 4 years ago

I do not think the configurationProvider setting is working. I simplified my .code-workspace multi root workspace file and stripped out the default includes, forced includes and defines.

Here is what it looks like:

{
    "folders": [
        {
            "path": "dock1500",
            "name": "app"
        },
        {
            "path": "zephyrproject/zephyr/boards/arm/scanimetrics_witap_isb",
            "name": "board"
        },
        {
            "path": "zephyrproject/zephyr",
            "name": "zephyr"
        },
        {
            "path": "zephyrproject/modules",
            "name": "modules"
        }
    ],
    "settings": {
        "C_Cpp.default.compilerPath": "/usr/local/bin/arm-none-eabi-gcc",
        "C_Cpp.default.cStandard": "c11",
        "C_Cpp.default.cppStandard": "c++17",
        "C_Cpp.default.intelliSenseMode": "gcc-x64",
        "files.associations": {
            "zephyr.h": "c",
            "kernel.h": "c",
            "kernel_includes.h": "c",
            "log.h": "c",
            "printk.h": "c",
            "littlefs.h": "c",
            "i2c.h": "c",
            "usb_device.h": "c",
            "soc.h": "c",
            "samd21g18a.h": "c",
            "power.h": "c",
            "watchdog.h": "c",
            "i2c_ll_stm32.h": "c",
            "init.h": "c",
            "device.h": "c",
            "cpu.h": "c",
            "generated_dts_board.h": "c",
            "system_timer.h": "c",
            "clock_control.h": "c",
            "sys_clock.h": "c",
            "dma.h": "c",
            "hwinfo.h": "c",
            "gpio.h": "c",
            "errno.h": "c",
            "stdio.h": "c",
            "version.h": "c",
            "spi.h": "c",
            "*.overlay": "dts",
            "sam0_eic.h": "c",
            "gpio_utils.h": "c",
            "led.h": "c"
        },
        "terminal.integrated.env.osx": {
            "ZEPHYR_BASE": "${workspaceFolder:zephyr}",
            "ZEPHYR_TOOLCHAIN_VARIANT": "gnuarmemb",
            "GNUARMEMB_TOOLCHAIN_PATH": "/usr/local/",
            "PATH": "$ZEPHYR_BASE/scripts:${env:PATH}"
        },
        "cmake.configureOnOpen": true,
        "editor.tabSize": 8,
        "editor.insertSpaces": false
    }
}

Here is the c/cpp log diagnostics output:

-------- Diagnostics - 3/22/2020, 2:58:52 PM
Version: 0.27.0-insiders3
Current Configuration:
{
    "name": "CMake-Tools",
    "configurationProvider": "vector-of-bool.cmake-tools",
    "compilerPath": "/usr/local/bin/arm-none-eabi-gcc",
    "cStandard": "c11",
    "cppStandard": "c++17",
    "intelliSenseMode": "gcc-x64",
    "compilerArgs": [],
    "browse": {
        "limitSymbolsToIncludedHeaders": true
    }
}
Translation Unit Mappings:
[ /Users/stevenslupsky/Documents/source/dock1500/src/main.c ]:
    /Users/stevenslupsky/Documents/source/dock1500/src/main.c
Translation Unit Configurations:
[ /Users/stevenslupsky/Documents/source/dock1500/src/main.c ]:
    Process ID: 16822
    Memory Usage: 14 MB
    Compiler Path: /usr/local/bin/arm-none-eabi-gcc
    Includes:
        /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/lib/gcc/arm-none-eabi/8.2.1/include
        /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/lib/gcc/arm-none-eabi/8.2.1/include-fixed
        /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/arm-none-eabi/include
    Standard Version: c11
    IntelliSense Mode: gcc-x64
    Other Flags:
        --gcc
        --gnu_version=80201
Total Memory Usage: 14 MB

As you can see, there are no include paths provided to the translation units by the CMake-Tools extension.

So, I think the earlier work I did was picking up a compile_commands.json file because there was a default setting in the .code-workspace file. I incorrectly assumed that default setting was being ignored and the configurationProvider setting was providing the relevant information.

My understanding is that the configurationProvider setting enables CMake-Tools to provide the include paths, defines, and other compiler information to the c/cpp extension? So, shouldn't that information appear in the output of the c/cpp Log Diagnostics?

sslupsky commented 4 years ago

I posted a comment here https://github.com/microsoft/vscode-cpptools/issues/5160#issuecomment-602279281

It appears like I am almost there. I think only the Go to Definition on #includes is not working as described here https://github.com/microsoft/vscode-cpptools/issues/2564.

I still do not understand why the configurationProvider setting is not working but the default compile_commands.json setting in the .code-workspace file configures the workspace properly.

Thanks for the pointers. My configuration is not perfect but I have made some improvement.

andreeis commented 4 years ago

@sslupsky, regarding the CMake Tools extension, is there anything else that is not working properly and you'd like us to investigate? If not, we would like to close this issue.

sslupsky commented 4 years ago

@andreeis I believe the outstanding issue is that the CMake Tools extension is not providing the configuration. Or, it is and c-cpp is ignoring it. I do not know how to tell which.

The only way I could get my configurations to work was to set the default "compile_commands.json" property in my multi root .code-workspace file.

sslupsky commented 4 years ago

@andreeis @bobbrow The other thing that comes to mind is to check with Bob regarding the zephyr integration. It is a rather complicated CMake setup. The zephyr team created a meta tool called "west" written in python that provides a user friendly build command. I am not sure if CMake Tools is or can be made compatible with this workflow. It would be great if it could. I think Bob was looking a bit more into zephyr but had some problems with the install. I am not clear if he resolved those issue or not.

github-actions[bot] commented 9 months ago

This issue is now marked as 'stale-old' due to there being no activity on it for the past 720 days. Unless the 'stale-old' label is removed or the issue is commented on, this will be remain open for at least 14 days and then it may be closed. If you would like to make this issue exempt from getting stale, please add the 'stale-exempt' label.