Repository navigation
Support cross-compilation configurations for IntelliSense #1083
Description
I am sometimes working on my project using a cross-compilation toolchain (for example, working on a Mac laptop; the project targets Linux). I tried to configure IntelliSense to only search the project and the cross-compilation sysroot. But I got this error:
file: 'file:///<redacted>.cc'
severity: 'Info'
message: 'cannot open source file "Availability.h" (dependency of "<redacted>.h")'
at: '1,1'
source: ''
This is of course a macOS header. I am guessing the indexer might be scanning hard-coded host paths. It seems likely that to properly support cross-compilation, there would need to be a sysroot parameter to act as a final catch-all.
Activity
sean-mcmanus commentedon Sep 30, 2017
What is the configuration you're using in c_cpp_properties.json? It sounds like it may be using the macFrameworkPath. We don't scan any hard-coded host paths that aren't in the c_cpp_properties.json.
jfroy commentedon Oct 6, 2017
This is my c_cpp_properties.json, with minor edits for confidentiality.
{ "configurations": [ { "name": "Foo", "includePath": [ "${workspaceRoot}", "${workspaceRoot}/build/vscode/gen", "${workspaceRoot}/build/vscode/GLog-prefix/install/include", "${workspaceRoot}/third_party/gflags/include/linux", "${workspaceRoot}/third_party/googletest/googletest/include", "${workspaceRoot}/third_party/protobuf/src", "${workspaceRoot}/tools/sdk/toolchain/include/c++/v1", "${workspaceRoot}/tools/sdk/toolchain/lib/clang/4.0.1/include", "${workspaceRoot}/tools/sdk/sysroot/usr/include", "${workspaceRoot}/tools/sdk/sysroot/usr/include/x86_64-linux-gnu" ], "defines": [ ], "intelliSenseMode": "clang-x64", "browse": { "path": [ "${workspaceRoot}", "${workspaceRoot}/build/vscode/gen", "${workspaceRoot}/build/vscode/GLog-prefix/install/include", "${workspaceRoot}/third_party/gflags/include/linux", "${workspaceRoot}/third_party/googletest/googletest/include", "${workspaceRoot}/third_party/protobuf/src", "${workspaceRoot}/tools/sdk/toolchain/include/c++/v1", "${workspaceRoot}/tools/sdk/toolchain/lib/clang/4.0.1/include", "${workspaceRoot}/tools/sdk/sysroot/usr/include", "${workspaceRoot}/tools/sdk/sysroot/usr/include/x86_64-linux-gnu" ], "limitSymbolsToIncludedHeaders": true, "databaseFilename": "" } } ], "version": 3 }Using VSCode 1.17.0 (1.17.0), ms-vscode.cpptools 0.13.1
llatta commentedon Oct 22, 2017
I'm running into the same issue, cross compiling emscripten code from a Mac. It seems to be caused by some headers doing some
If I manually add
#undef __APPLE__at the top of my source file, the intellisense errors go away. Of course modifying the source in this way is ugly. Is there a way to add this to the config options for the plugin? Either something to allow undefining options, or maybe an option for preventing whatever default defines the intellisense engine adds?jfroy commentedon Oct 22, 2017
Ah, this good insight. The setting we may be missing the clang's -target. If we could specify that for the indexer, then we could convey the target platform and all the relevant compiler built-in defines would be set correctly.
sean-mcmanus commentedon Oct 23, 2017
You can use
clang -v -E -x c++ - < /dev/nullto see what includePath/defines you should use, but we don't currently have a way to remove defines that are hard-coded (they're currently built into the mac binary), but I think we eventually plan to make this configurable.bobbrow commentedon Oct 23, 2017
I think Lutz Latta (@llatta) nailed it. IntelliSense built for Mac always has
__APPLE__defined. The engine API doesn't currently give us an option for changing the target. I'll need to ask for it.rizickus commentedon Jan 19, 2018
Is there any progress regarding this issue?
sean-mcmanus commentedon Jan 19, 2018
Rimantas (@rizickus) No progress has been made on this, but we just need to change the compile-time Linux/Mac defines to be based on some new setting. In regards to _WIN32, that should stop being defined when you change the intelliSenseMode to "clang-x64" -- do you use a cl.exe or gcc/clang when _WIN32 shouldn't be defined? Or make intelliSenseMode have more possible values for all the compiler/OS combinations.
rizickus commentedon Jan 23, 2018
Yes, changing to "clang-x64" removed _WIN32 define, thanks! I am using armclang.
cody-greene commentedon Apr 17, 2018
Is there an issue# on the main vscode repo for for this option that I can track? And possibly help with? I'd love to use vscode + mingw to cross compile for windows from mac/linux.
sean-mcmanus commentedon Apr 17, 2018
Cody Greene (@cody-greene) The main vscode repo wouldn't be tracking this issue, because it's a C++ extension issue. The TODO work is on our closed-source side so there's nothing you could help with. We support cross-compilation in general via setting the compilerPath/intelliSenseMode, but there are just a bunch of hardcoded defines, mostly regarding Mac that can't be changed yet (using forcedInclude to do #undef might be a workaround).
33 remaining items
sean-mcmanus commentedon Dec 28, 2020
Sergey (@icegood) Yeah, it's being worked on for the next release. We'll post an update here when it's available to try in an insiders release.
zakkie commentedon Jan 17, 2021
I'm working on a project that targets embedded systems.
#6745 added definitions for Linux, macOS, WIndows, but no other definitions.
I think it would be nice to have a option that allows users to define their own settings for a particular system without automatically adding them. (like
"intelliSenseMode": "bare")icegood commentedon Jan 20, 2021
Just checked and it seems to work as expected. Good job!
One more question: my project is cmake-based and contains custom third party libraries that provide custom header paths. Is it possible to propagate these paths from "CMake Tools" plugin to vscode-cpptools to make search/highlight correct? Or all we can do is to manually add all these extra headers in custom paths inside cpptools?
sean-mcmanus commentedon Jan 21, 2021
Sergey (@icegood) The PR at https://github.com/microsoft/vscode-cpptools/pull/6823/files enables cpptools to consume the new IntelliSense modes, but CMake-Tools hasn't been changed yet to send them. Is that what you're referring to? The existing releases should already support configuring IntelliSense includes/defines from CMake-Tools, but it's just the cross-compilation that is new.
sean-mcmanus commentedon Jan 21, 2021
Fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/1.2.0-insiders2 (although there are some related TODOs, such as https://github.com/microsoft/vscode-cpptools/pull/6823/files mentioned earlier).
bobbrow commentedon Feb 8, 2021
Yes, the old ("generic") enum values always implicitly add the platform based on your host OS. So if you use the extension on linux with 'gcc-arm', we will promote that to 'linux-gcc-arm'. The new enum values allow you to target other platforms.
sean-mcmanus commentedon Feb 8, 2021
Pablo Rodriguez (@pablojrl123) See #6813