Issues with vscode-zig zig path config and test runner

Help
,
1

Selecting a shell script (on windows, so a .cmd or .bat file) for the Zig path after choosing “Manually Specify Path” from the status bar button in VS Code sends an error notification Failed to run 'C:\path\to\zig.cmd version'!

It seems that this might happen because the getVersion check in zigUtil.ts calls child_process.execFileSync, whereas running a shell script requires calling child_process.execSync.

I presume this is also why we have to specify "type": "process" | "shell" in tasks.json, though I don’t know node that well. Just trying to do a little due diligence.

Also, it’s not clear to me from poking at it: is there an association between what I put for zig.path in settings.json and the zig version selected from the status bar button?

I did manage to get tests to run once, but now I’m in a state where it can’t find any tests, and the “Zig tests” profile is not selectable from the dropdown in the vscode tests sidebar.

I do have a test task set up in tasks.json which builds and runs and passes, so it should run. I had a path in workspace settings.json with a vscode variable in the string (${workspaceFolder}/tools/zig.cmd), and that seems to also cause problems, even if I change the path to point to the actual zig.exe rather than the shell script.

The reason I had this is because I have a setup script for collaborators to run which just downloads the right version of zig to a .gitignored folder. It’s also been helpful for me to quickly swap to different versions to see if I need to change any code to keep current with nightly, or to build with a locally build zig for the (now-rare :slight_smile:) occasional compiler crash or miscompile. I realize the extension will now manage versions for me, but I’m not sure I want to abandon my scripts and tie the workflow to vscode.

Anyone here run into similar issues and have Pro Tips to offer?

My ideal is that I can still use my zig.cmd script and tell vscode-zig to run that whenever it wants to run zig. This has been working fine for zig build check steps. Autocomplete and zig fmt on save all work fine with the shell script.

Posting here rather than the issue tracker since I think I need a little more info on how it’s all intended to work with the new version-managing hotness.

2

It seams like the argument ' version' is included in the path of the script.
Try something like ['C:\path\to\zig.cmd', 'version']

3

That’s not the issue, as I mentioned setting it to absolute path to an exe works fine. This is in the vscode-zig extension code, not my tasks.json or launch.json

The extension handles passing the right argument here:

4

I am guessing that the extension runs zig version as a setup test.

  • In zig.cmd how do you run zig.exe?
  • If you run from any directory C:\path\to\zig.cmd version do you get the same output and errorlevel as zig version?
5

This is the contents of zig.cmd:

@%~dp0\zig-windows-x86_64-0.14.0-dev.1570+8ddce90e6\zig.exe %*

It behaves exactly like the running the executable would work, and errorlevel is returned appropriately since this is the only line in there:

PS C:\Users\micha\dev\zigproject> tools/zig.cmd version; write-host $LastExitCode
0.14.0-dev.1570+8ddce90e6
0

I’ve been using it as my primary way to invoke zig.exe for the past few years, with a build task defined like this:

{
    "label": "Zig Build",
    "type": "shell",
    "command": "tools/zig.cmd",
    "args": [
        "build",
        "-freference-trace",
        "--summary", "all"
    ],
}

The "type": "shell" is necessary, which is what makes me think that maybe the plugin would need to call child_process.exec* differently to run the command through the shell in order for this script to work.

6

Do you start visual studio code from the command line?
This must work for you:

cd dev/zigproject
code .
7

I think you need a real exe file, because it is unlikely that every part will have some kind of support for executing shell scripts, usually programs that use executables avoid the ability to use shell scripts where they aren’t expected.

Maybe you could create a small zig program that acts as a replacement for your shell script, for example it could act as an executable that redirects to a subprocess (although I don’t know how much work it would be to faithfully pipe and forward everything to the child process), then you could have a file alongside the executable that contains the path to the real exe.

On linux I just create a symbolic link for such redirection using a whole shell script / wrapper seems like too much, for what should be simple.

Apparently there are also ways to create symbolic links on windows, but I have no experience with them, maybe worth a try, because if that is enough it could simplify things.

2 Likes