Replies: 1 comment 11 replies
-
Hi @KaeLL . We have had a number of users report issues due to non-standard
Normally, a compiler query is only necessary if the command line is unique in some way other than the input filename (and other known arguments that correspond with that file, such as
Does
Could you provide the C/C++ channel output for that scenario? Does the warning occur when opening a file that does not have an entry in |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Colengms, I'm a bit of a newb for vscode, but interested in maximizing integration for my company, Epic Games, and our Product, Unreal Engine. So, bear with me a bit. I found this thread which seems to ask meaningful high level usage questions for the extension. Regarding your comment here:
For Unreal Engine we currently generate compile_commands.json for each Configuration. Each compile_commands_.json lists each source file, compiler command line, and working directory. I gather from your comment that this is mainly for reverse engineering (from cmdline params and rsp files) the compiler incantation for code sense features when the document is active in the vscode IDE. I've been looking around to also verify that the compiler incantation is correct for "Compile single file" behavior, but I can't quite seem to figure out the entry point for that feature. The "build active file" feature described here: https://code.visualstudio.com/docs/languages/cpp seems to vanish when you have a code-workspace with fully configured compile_commands. Is there no entry point to have vscode execute the specified compile commands for source files where this makes sense (.cpp files for example)? I couldn't find much specification/documentation about the command_commands.json such that a file listed could be flagged as "Compilable" and thus activate a hotkey to compile it. Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
@gorlak The compile_commands.json integration just applies to configuring IntelliSense and isn't used by our extension for any compilation. The build active file feature uses the command information in a tasks.json to build. |
Beta Was this translation helpful? Give feedback.
-
|
That makes the file name pretty confusing 😊 Given we have the compiler path and it's arguments, it would seem ripe to expose a single-file-compile or preprocess-only feature via compile_commands.json. Frequently some engineering work is made quicker by just compiling a single file to obj or preprocessed source, and it's very difficult to build that feature on the back of targets designed to build an entire module or program, which is what tasks.json is more designed for. I also shudder to think how long it would take to open a code workspace, much less select the proper task to run, if there was a task for compiling every source file, and another for preprocessing every source file. For a project like UnrealEngine that may be back-breaking amount of data for code to handle. AFAIK the tasks data interface already lacks a way to matrix/permute the available configurations (like configuration/platform in Visual Studio). Worst case this could yield a task runner for -Geoff |
Beta Was this translation helpful? Give feedback.
-
|
@gorlak We have a work item to track improving the build experience at #7497 -- that new build/run mechanism would use the compile_commands.json set if it's set by IntelliSense and would build all the files and then run or debug the executable. You could file a feature request for a build single file option that uses compile_commands.json (or we could open one for you). |
Beta Was this translation helpful? Give feedback.
-
|
Sure thing! #8345 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Before diving into the questions, a little background. I'm developing for an ESP32-based platform with the ESP-IDFramework.
I was curious about how clever the extension is by default after noticing that it was failing to resolve the definition of a function call inside IDF.
Let's begin with my
c_cpp_properties.json{ "configurations": [ { "name": "idf", "intelliSenseMode": "linux-gcc-x86", // "compilerPath": "/tools/xtensa-esp32-elf/esp-2021r1-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc", "compileCommands": "${workspaceFolder}/build/compile_commands.json" } ], "version": 4 }Next is the complete output of the extension at Debug level for reference:
Click here to expand the 1641 lines long log
Now, to the questions.
Line 1234 to 1236 indicate that include folders from my machine will be indexed, regardless of whether
compilerPathis set or not. WhencompilerPathis not set, it finds clang on my machine, which won't be used at all, and causes the issue mentioned on question 3 below. Seems clear that the extension doesn't take information solely from thecompile_commands.jsonfile and it doesn't parse it before stuff like looking for compilers. The question is: why? Seems less than ideal, to say the least? The extension should figure outcompilerPath,intelliSenseMode,cStandard,cppStandard, and every other configuration that's not specified in thec_cpp_properties.jsonfile on its own from thecompiler_commands.jsonfile if the user sets it. Apparently, it already doing this, just not in the ideal order, or am I wrong? It prevents the extension from loading unnecessary crap like compilers that won't be used and their configurations, as well as it allows for more informed decisions down the road that at least help avoid issues (more on this in question 3).In the logs, I get 1004 attempts to get defaults from the compilers, 982 for the C compiler and 22 for the C++ compiler, regardless of whether
compilerPathis set or not. I also get 25 failures to query the compiler and fallbacks to no bitness (lines 21 to 27 in the log repeatedly), despite manually running the compiler query command with no bitness (no-m32or-m64) in my terminal and it working correctly. Why? What's happening with these 2 procedures? Why such a high amount? Is it really failing and trying again that many times? I'm not sure by looking at only the attempts to get the defaults, but from the queries related to the bitness, it seems pretty clear that it's failing all the time, and there's something terribly wrong going on.What's the relationship between
compilerPathandintelliSenseMode? Not settingcompilerPathseems to make the extension go bonkers. I get the warning below. It doesn't really make sense. Granted, I do have clang on my machine, but it defaults to the x86 variant? Why? Is it a middle-ground between my choice and the fact that it found clang in my x64 machine? And it doesn't change it back after parsingcompile_commands.jsonas per the fact that it doesn't give me another warning saying it changed back. What's with it?Beta Was this translation helpful? Give feedback.
All reactions