Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Other" commands line args (-std, -mcpu, etc.) from compile_commands.json aren't used for system include/define querying #1755

Open
sean-mcmanus opened this Issue Mar 29, 2018 · 7 comments

Comments

Projects
None yet
4 participants
@sean-mcmanus
Copy link
Collaborator

sean-mcmanus commented Mar 29, 2018

This was intentionally delayed for later. If the args are needed the workaround is to set them in the compilerPath, but it's global for all files. Is this scenario important to anyone? We didn't get complaints about this in the 0.16.0 insider releases.

UPDATE: This is only for the special flags that modify compiler defaults, not the normal -D/I, e.g. args like -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16.

UPDATE: -std is sort of special case because it also sets flags we pass to our compiler -- not sure if it should overwrite the cppStandard or cStandard (which have a smaller range of values than -std).

@Ju57iCe

This comment has been minimized.

Copy link

Ju57iCe commented Mar 29, 2018

Could you give us a timeline when this will get attention? I think this will be quite useful as this will clear most of the false positives in the Problems tab and would not require manual work to edit the vscode configuration files.

Currently I am working on a large project that uses CMake. The thing that bugs me a bit is the integration with CMake.

In the perfect case I would be able to load a CMake project which will then:

  1. Load all of the source files for the project with an option to show the rest of the files in the project folders that are not included for compilation
  2. The intellisense database will then be built from the source file included in the CMake (or just the compile_commands.json that has been dumped by the cmake)
  3. Option to have multiple CMake projects open (similar to the workspace notion) with their own intellisense databases, include paths, etc.

I not sure if this is the right issue to post into, but I think it is connected. Also my suggestion will probably include work in the main VSCode repository. And last, but not least, thank you for the great work and keep up!

@sean-mcmanus

This comment has been minimized.

Copy link
Collaborator Author

sean-mcmanus commented Mar 29, 2018

Your issues sounds different. If you're using CMake, you should already be able to set -DCMAKE_EXPORT_COMPILE_COMMANDS=1 and set the path in the compileCommands property in c_cpp_properties.json. This should work in most scenarios, but special cases may have issues that require the compilerPath to also be set, optionally with args. We already support the basic include path and defines args in the compileCommands, it's just the "other" ones we don't handle on a per-file basis and would have be globally set in the compilerPath until this is implemented.

And there's a bug on Windows where non-cl.exe compilers require the compilerPath to be set if compileCommands is used.

Also, the browse.path (root path for all workspace symbol parsing) is not set by compileCommands or compilerPath yet, but the browse.path is recursive and not order dependen, so it's easier to set.

@Ju57iCe

This comment has been minimized.

Copy link

Ju57iCe commented Mar 29, 2018

Thank you for the reply. I was talking about a better out of the box experience for CMake projects and reading compile_commands.json is a good step to it. But the problem is slightly different:

repo root

  • .vscode
  • build
  • source folder 1
  • source folder 2
  • source folder 3
  • libs
  • tools (uses stuff from libs)
    • tool 1
    • tool 2

Assuming CMake for all executables and libraries and the repo root is opened in VSCode.
Currently in the c_cpp_properties.json I can only add the compile_commands.json from one of the cmake projects. For the rest of them I still get "cannot open source file" error. Yes, I can still add them manually as include paths, but it kinda kills the idea of using compile_commands.json.

Edit: Are there any obstacles or complications for setting the browse path from compileCommands? This will allow loading of multiple projects each of with its own files with the multiple workspace concept? If no obstacles, I might try to implement it.

@loaden

This comment has been minimized.

Copy link

loaden commented Mar 29, 2018

I think this is necessary. In the args, there are some option, e.g. '-D' , '-I' sounds useful.

{
"directory": "d:/qpsoft/projects/nana/build",
"command": "D:\qpSOFT\VSCode\VSCode_64-bit\MinGW\bin\g++.exe -DNANA_IGNORE_CONF -DVERBOSE_PREPROCESSOR -DWIN32 -I../include -std=c++14 -Wall -g -g -fmax-errors=3 -std=gnu++14 -o CMakeFiles\nana.dir\source\gui\widgets\button.cpp.obj -c D:\qpSOFT\Projects\Nana\source\gui\widgets\button.cpp",
"file": "D:/qpSOFT/Projects/Nana/source/gui/widgets/button.cpp"
},

We seems needs:

-DNANA_IGNORE_CONF -DVERBOSE_PREPROCESSOR -DWIN32 -I../include

@bobbrow

This comment has been minimized.

Copy link
Member

bobbrow commented Mar 29, 2018

@loaden, the extension does parse out the -D and -I options from the "command" when the IntelliSense engine starts. Sean was referring to the args that would have an effect on the system include path or defines when the compiler is queried for its default values.

@Ju57iCe, we should be able to change the compileCommands property to accept an array of strings instead of just a single string. As a workaround in the meantime, you could create a "configuration" for each of your source folders and switch between them when working on the source files in the different projects. I have been considering adding a property to the configuration object that allows you to specify a glob pattern for the files that the configuration pertains to. This would allow the extension to auto-switch between configs depending on the active source file.

@sean-mcmanus sean-mcmanus changed the title Commands line args from compile_commands.json aren't used for system include/define querying "Other" commands line args from compile_commands.json aren't used for system include/define querying Mar 29, 2018

@sean-mcmanus

This comment has been minimized.

Copy link
Collaborator Author

sean-mcmanus commented Mar 29, 2018

@loaden @bobbrow Yeah, sorry for not being more explicit about the args I was talking about.

@Ju57iCe Another workaround might be to use multiple workspace roots, each of which has its own c_cpp_properties.json. We have a work item to use compileCommands to populate the browse.path.

@Ju57iCe

This comment has been minimized.

Copy link

Ju57iCe commented Mar 30, 2018

Thanks a bunch for the suggestions. And populating the browse.path from the compile commands will be perfect. Keep up the good work guys!

@sean-mcmanus sean-mcmanus changed the title "Other" commands line args from compile_commands.json aren't used for system include/define querying "Other" commands line args (-std, -mcpu, etc.) from compile_commands.json aren't used for system include/define querying May 15, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.