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

CMakePresets: "warnings" field settings are not passed on to CMake #2009

Closed
hwmaier opened this issue Jul 23, 2021 · 3 comments
Closed

CMakePresets: "warnings" field settings are not passed on to CMake #2009

hwmaier opened this issue Jul 23, 2021 · 3 comments
Assignees
Labels
Feature: presets fixed (release pending) fixed in pre-release and is pending official release quick fix the fix is estimated to be quick
Projects
Milestone

Comments

@hwmaier
Copy link

hwmaier commented Jul 23, 2021

When creating the command line to invoke CMake the warnings field is ignored and it is impossible to pass warning command line arguments to CMake. For example in this case --no-warn-unused-cli shall be passed on to CMake.

Example:

    "configurePresets": [
        {
           ...
            "warnings": {"unusedCli": false},
           ...
        },

As a side note, this issue would not occur if this plugin would use the --preset argument to invoke CMake rather than building its own command line.

@bobbrow
Copy link
Member

bobbrow commented Jul 26, 2021

Thank you for reporting this issue. Looks like a simple logic mistake in the code. @xisui-MSFT could you fix this real quick?

preset.warnings.unusedCli && result.push('--no-warn-unused-cli');


As a side note, this issue would not occur if this plugin would use the --preset argument to invoke CMake rather than building its own command line.

Yes, this is likely possible, but Kitware has requested that IDE's/editors do their own parsing instead of using --preset (reference)

@bobbrow bobbrow added Feature: presets quick fix the fix is estimated to be quick labels Jul 26, 2021
@bobbrow bobbrow added this to the 1.8.0 milestone Jul 26, 2021
@bobbrow bobbrow added this to Triage in 1.8.0 via automation Jul 26, 2021
@bobbrow bobbrow moved this from Triage to To do in 1.8.0 Jul 26, 2021
@hwmaier
Copy link
Author

hwmaier commented Jul 26, 2021

As a side note, this issue would not occur if this plugin would use the --preset argument to invoke CMake rather than building its own command line.

Yes, this is likely possible, but Kitware has requested that IDE's/editors do their own parsing instead of using --preset (reference)

Also Thanks for this explanation. I have been wondering what the rationale was to reconstruct rather using the --preset argument. I suggest to put that explanation into the doc as I am sure it comes up again.

@bobbrow bobbrow moved this from To do to Done in 1.8.0 Jul 27, 2021
@bobbrow bobbrow added the fixed (release pending) fixed in pre-release and is pending official release label Jul 27, 2021
@bobbrow
Copy link
Member

bobbrow commented Jul 27, 2021

I'm not sure which doc would be an appropriate place for it. People would ask anyway. 😅

We committed a fix for this. If you want to try it out, you can download the VSIX here: https://github.com/microsoft/vscode-cmake-tools/suites/3342925255/artifacts/78474075
and then run the "Install from VSIX..." command in VS Code.

@bobbrow bobbrow closed this as completed Aug 26, 2021
@github-actions github-actions bot locked and limited conversation to collaborators Jan 29, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Feature: presets fixed (release pending) fixed in pre-release and is pending official release quick fix the fix is estimated to be quick
Projects
No open projects
1.8.0
Done
Development

No branches or pull requests

3 participants