Not always working out-of-the-box on Windows

[Slion]

It looks like it install the tools and SDK in USERPROFILE but then tries to run them from HOME environment variables. So on systems where they differ it just won't work without manually adjusting the paths.

To fix it I had to edit .vscode/setting.json and .vscode/cmake-kits.json, replacing some userHome and env:HOME with env:USERPROFILE.

[will-v-pi]

Do you have any log output showing the incorrect paths? This seems like a VS Code issue, as the ${userHome} variable is provided directly from VS Code (https://code.visualstudio.com/docs/editor/variables-reference), so if that's pointing to an incorrect location on some systems then that would be a VS Code issue.

The extension works fine on my Windows laptop, which doesn't have the HOME environment variable set, only USERPROFILE, so this may be an issue with VS Code picking up the set HOME environment variable.

[Slion]

Sorry no logs, updated the description to mention env:HOME.

[will-v-pi]

This extension should not use env:HOME on Windows - those sections in those files are for MacOS and Linux only.

I can't reproduce this myself with HOME and USERPROFILE set to different values - could you try adding the following tasks to tasks.json and running the tasks, to see what userHome and env:HOME are resolving to on your system?

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "userHome",
            "type": "shell",
            "command": "echo ${userHome}",
            "problemMatcher": []
        },
        {
            "label": "envHome",
            "type": "shell",
            "command": "echo ${env:HOME}",
            "problemMatcher": []
        }
    ]
}

[Slion]

Looks like they both give the correct path to USERPROFILE weirdly enough.

[Slion]

How to set the board to Pico W manually? When I use the extension UI panel it looks like it is tripped by that path issue too, gives an error message and I still can't find "pico/cyw43_arch.h" .

[will-v-pi]

You can just manually change the set(PICO_BOARD ...) line

[Slion]

You can just manually change the set(PICO_BOARD ...) line

Yup that does it, directly in cmake:

set(PICO_BOARD "pico_w")

[Slion]

Now I have tons of C++ linker errors and no idea how to fix that.

[Slion]

Looks like they both give the correct path to USERPROFILE weirdly enough.

Really weird, in fact my system does not have a HOME environment variable but it has HOMEDRIVE and HOMEPATH and those were used instead of USERPROFILE.

Maybe try to repro with those environment variables :

HOMEDRIVE                      C:
HOMEPATH                       \Wrong\Path

[Slion]

Now I have tons of C++ linker errors and no idea how to fix that.

That was using GCC v13.2.1. If I switch back to GCC v10.3.1 it works. I should open an issue on pico-sdk I guess.

[will-v-pi]

I'm afraid I'm unable to override those variables so cannot reproduce this, but given the linker errors you're getting too it sounds like your system is broken in some way - could you post the error messages and logs you are getting, and also post the output from the developer console (Help -> Toggle Developer Tools)?

[Slion]

I'm afraid I'm unable to override those variables so cannot reproduce this,

Are they matching USERPROFILE on your system?

[Slion]

This extension should not use env:HOME on Windows - those sections in those files are for MacOS and Linux only.

Yeah I realised that too as I was doing it. Not sure exactly which of my changes did the trick in the end. I just put env:USERPROFILE everywhere it made sense. I did not do a commit of the broken import result so I don't have the exact diffs but I'm pretty sure it only replaced userHome and env:HOME and yes I certainly broke the Linux and MacOS build in the process 😁 If I can't build on Windows nobody will 🤣

[Slion]

given the linker errors you're getting too it sounds like your system is broken in some way

Only with the extension's newer toolchain. When using the toolchain from the now retired Windows SDK installer it works. I ought to try installing the older GCC toolchain through the extension and see if that works.

I'm still targeting SDK v1.5.1 could it be it does not work with GCC v13.2.1?

[Slion]

Similar C++ linker errors when trying to build https://github.com/pimoroni/pimoroni-pico/tree/main/examples/pico_display_2: pico-code-link-errors.txt Though I don't think that's related to my path issues. I'm planning to try the extension on another machine to get to the bottom of that.

[Suresh6060]

will pico-sdk ever work on windows 7 ?

during compile cmake.. reports that it requires picotool to be a minimum version 2.0.0 , but the picotool that was downloaded is version ="" . cmake automatic download cuts of at 22% . I finally gave up rpi and deleted everything. vscode will not install pico-sdk saying it require higher version of vscode. Only thing working is thonny and mu . tried using wifi. But it gets disconnected randomly , making it unusable for any serious projects. git 64 does work, had to install git 32. But gets stuck at picotool. does any one use this windows 7 ?

[will-v-pi]

will pico-sdk ever work on windows 7 ?

during compile cmake.. reports that it requires picotool to be a minimum version 2.0.0 , but the picotool that was downloaded is version ="" . cmake automatic download cuts of at 22% . I finally gave up rpi and deleted everything. vscode will not install pico-sdk saying it require higher version of vscode. Only thing working is thonny and mu . tried using wifi. But it gets disconnected randomly , making it unusable for any serious projects. git 64 does work, had to install git 32. But gets stuck at picotool. does any one use this windows 7 ?

This is completely unrelated to this issue - see #76 for Windows 7 details/discussion

[will-v-pi]

Closing this now, as the C++ linker errors are fixed, and the userHome issue seems to be a VS Code bug