Puzzling omission of include directives from `compile_commands.json`

[greenc-FNAL]

With Windsurf/Intellisense in VSCode, some headers and associated symbols (e.g. oneapi/tbb/global_control.h and control_t) are being flagged as unavailable/unknown. Explicitly mentioning the directories in c_cpp_properties.json is unsuccessful because includePath is ignored when compile_commands.json is present (as a result of cmake -DCMAKE_EXPORT_COMPILE_COMMANDS).

AI analysis has this to say:

Following your rebuild, I re-checked where the headers live, inspected the regenerated compile_commands.json, and mapped out what Windsurf needs so it can resolve those includes again.

what I found

• The TBB headers Windsurf is complaining about are present under tbb (and the 2022.2 directory that symlinks to it), so the files themselves are on disk.
• The new compile_commands.json still doesn’t list that directory. For concurrency.cpp, CMake only emits -I${workspaceFolder}/srcs/phlex plus two -isystem entries that point to the plain .../view/include view, which does not contain oneapi/tbb.
  Windsurf (via the cpptools IntelliSense engine) ignores the manual C_Cpp.default.includePath when compileCommands is present, so it never sees the TBB path and continues to warn even though the actual compiler succeeds thanks to environment-provided defaults.

suggested fixes

• Teach CMake to pass the TBB includes explicitly on the command line so they land in compile_commands.json. A low-risk pattern is:

  get_target_property(_tbb_inc TBB::tbb INTERFACE_INCLUDE_DIRECTORIES)
  if(_tbb_inc)
    target_include_directories(phlex_core PRIVATE ${_tbb_inc})
    # repeat for any other targets that directly include TBB headers
  endif()
  

  Regenerate the build (cmake --preset default ...) and the JSON should then contain -isystem .../tbb/latest/include, clearing the squiggles on the next IntelliSense refresh.

• If you need a quicker, editor-only workaround, add the same include directory to C_Cpp.default.compilerArgs (for example "-isystem${workspaceFolder}/local/.spack-env/view/tbb/latest/include"). That forces cpptools to inject the path even while it honors compileCommands, but keeping CMake authoritative is the longer-term fix.

I don't like either of the solutions, so I'd like to spend a little time looking at the CMake code to try to understand why the -I directives aren't showing up in the compile commands the way I'd expect.