skip to Main Content

I’m learning C++ from https://youtu.be/8jLOx1hD3_o?t=4558, I’m on Arch Linux. While setting up tasks.json file with the code:

{
    "version": "2.0.0",
    "tasks": [
        {
            "type": "cppbuild",
            "label": "Build with G++",
            "command": "/usr/bin/g++",
            "args": [
                "-fdiagnostics-color=always",
                "-g",
                "-std=c++20",
                "${workspaceFolder}/*.cpp",
                "-o",
                "${fileDirname}/rooster"
            ],
            "options": {
                "cwd": "${fileDirname}"
            },
            "problemMatcher": [
                "$gcc"
            ],
            "group": "build",
            "detail": "compiler: /usr/bin/g++"
        }
    ]
}

it’s giving the error:

Executing task: Build with G++ 

Starting build...
/usr/bin/g++ -fdiagnostics-color=always -g -std=c++20 '/home/stoner69/codes/C++20TemplateProject/*.cpp' -o /home/stoner69/codes/C++20TemplateProject/.vscode/rooster
cc1plus: fatal error: /home/stoner69/codes/C++20TemplateProject/*.cpp: No such file or directory
compilation terminated.

Build finished with error(s).

 *  The terminal process failed to launch (exit code: -1). 

but when I use :

"${workspaceFolder}/main.cpp"

it’s running properly. I couldn’t find any logical error in this json file. Neither * and ** work. They get quoted, so they aren’t interpreted by a shell.

2

Answers


  1. According to a contributor to the C/C++ extension, this was by design, and a recent, intentional behaviour change for version 19.4.

    It has been reverted in version 19.5 after receiving feedback that it was disruptive and not aligned to conventional task args processing.

    I leave the following, which was the answer I wrote before the maintainers decided to revert the change for v19.5:


    See issue ticket Update 1.19.4 breaks wildcard operator ‘*’ in tasks.json code will not compile #12001. Quoting Colen’s comment there:

    When represented as an array, we do not expect arguments to contain shell escaping or other special shell characters. When present, they are now properly escaped. This recently changed, to address users’ issues with args that refer to paths (containing special characters) that not being properly escaped, resulting in failing commands.

    I believe the proper solution here would be either for us to add an addition field for a command line fragment (allowing a partial command line, where shell escaping would be expected/supported), or allow arguments to also be included in the "command" field (which seems appropriately named to do so). I think the later may be more straight-forward. (The compilerPath field in c_cpp_properties.json works this way.) I’d like to use this issue to track adding that.

    They do some more elaboration in this later comment.

    I.e. If you want globbing, supposedly, you have to switch to using a string for args instead of an array, and do any necessary shell quoting yourself.

    Warning: At the time of this writing, I actually am having issues using a string instead of an array for the args property of a cppbuild task. The schema doesn’t seem to recognize strings and insists that I use an array, and the task doesn’t seem to register properly if I insist on using a string… I’ve poked the maintainers about this and hopefully it gets fixed.

    I’ve seen some people suggest just rolling back your C/C++ extension and preventing it from automatic updates, but I would caution against this. This is by design, so it’s not going to go back to the old behaviour. For one thing, it’s not necessary, since you can just switch to using a string instead of an array. For another, by opting out of extension updates, you’re opting out of any and all further improvements that are made to the C/C++ extension in future updates.

    An unsolicited note: While you can get what you want by switching to a string, I’d suggest what I’d have suggested already when you started using multiple files for compilation: Look into using a build system or buildsystem generator. I’d suggest CMake. There’s a definite learning curve, but if you see yourself doing C/C++ development long term, it’s well worth it. Doing compilation like this results in a lot of unnecessary recompilation, which is one of the problems that a buildsystem solves (or compiler caching, or a combination of the two).

    Login or Signup to reply.
  2. This behavior was changed with some versions of 1.19, but we’ve seen the feedback and also recognize that this change in behavior takes us out of alignment with the way VS Code processes "args" for their tasks, so we’ve decided to revert the change. This will be fixed in 1.19.5.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search