Install script?

[thejpster]

I appreciate having pre-built binaries for your tools, but when I write instructions for my users to install them, I have to give specific Windows/macOS/Linux instructions so they get the right file and put it in the right place.

Is there scope here to write an installer, say, in bash, that works out the right platform aces the latest version and puts the tools in an appropriate place? This would make the instructions simpler, and make it easier to get something like picotool into a GitHub CI action.

[lurch]

These tools are designed to work in conjunction with https://github.com/raspberrypi/pico-vscode - is that a viable "installation route" for your users? See chapters 2 and 3 of https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf

Is there scope here to write an installer, say, in bash

I guess that means that you'd also need to write instructions about how to install bash on Windows? 😉

One thing to be aware of is that not all releases are a "full release" of every tool (see e.g. https://github.com/raspberrypi/pico-sdk-tools/releases/tag/v2.1.1-1 ), so I guess any installer-script would need to read in a metadata file, detailing which tools are in which releases? (e.g. see the files in https://github.com/raspberrypi/pico-vscode/tree/main/data/0.17.0 )

[thejpster]

VS Code - is that a viable "installation route" for your users?

For some, but as it's proprietary software, certainly not for all (and I for one am currently boycotting it due to its heavy 'AI' promotion and integration). And it doesn't help for CI.

windows

Yeah. Although I suspect my target audience mostly has git-bash for Windows installed. But being able to "winget install" the tools would be useful.

not all releases

Oh. That does make things more complicated.

Basically it feels like I need to reinvent rustup, and I don't want to do that. I could live with an apt repository, a brew tap/keg/whatever and a winget entry.

[lurch]

Oh, and I've just remembered that there's a version inter-dependency between pico-sdk and picotool too. i.e. certain versions of pico-sdk only work with certain versions of picotool, and vice-versa. I'm sure @will-v-pi will be able to share more details when he sees this issue.

[will-v-pi]

One of the main purposes of the VS Code extension was to have the same installation pathway on Windows/MacOS/Linux, rather than having separate apt/brew/winget entries. So I don’t think we plan on doing that.

Note that all the tools here can be used by downloading and extracting them to anywhere, setting some environment variables, and adding those places to the path, so they don’t have to be put in the “right place” - the picotool readme documents the picotool_DIR variable, which applies to pioasm_DIR as well, and then there’s PICO_TOOLCHAIN_PATH which is documented in the SDK.

Also, the VS Code extension is also available on the OVSX registry for use in things like VS Codium, if your objections are specific to the Microsoft VS Code.

[lurch]

not all releases

Oh. That does make things more complicated.

@will-v-pi To keep things simple, I guess a useful first-pass might be a latest.json file in this repo, with something like:

{
    "openocd": {
        "version": "0.12.0+dev",
        "release": "v2.2.0-1",
        "binaries": {
            "linux": {
                "aarch64": "https://github.com/raspberrypi/pico-sdk-tools/releases/download/v2.2.0-1/openocd-0.12.0+dev-aarch64-lin.tar.gz",
                "x86_64": "https://github.com/raspberrypi/pico-sdk-tools/releases/download/v2.2.0-1/openocd-0.12.0+dev-x86_64-lin.tar.gz"
            },
            "macos": {
                "arm64": "https://github.com/raspberrypi/pico-sdk-tools/releases/download/v2.2.0-1/openocd-0.12.0+dev-arm64-mac.zip",
                "x86_64": "https://github.com/raspberrypi/pico-sdk-tools/releases/download/v2.2.0-1/openocd-0.12.0+dev-x86_64-mac.zip"
            },
            "windows": {
                "x64": "https://github.com/raspberrypi/pico-sdk-tools/releases/download/v2.2.0-1/openocd-0.12.0+dev-x64-win.zip"
            }
        }
    },
// etc.
}

?

[will-v-pi]

not all releases

Oh. That does make things more complicated.

@will-v-pi To keep things simple, I guess a useful first-pass might be a latest.json file in this repo, with something like:

{
"openocd": {
"version": "0.12.0+dev",
"release": "v2.2.0-1",
"binaries": {
"linux": {
"aarch64": "https://github.com/raspberrypi/pico-sdk-tools/releases/download/v2.2.0-1/openocd-0.12.0+dev-aarch64-lin.tar.gz",
"x86_64": "https://github.com/raspberrypi/pico-sdk-tools/releases/download/v2.2.0-1/openocd-0.12.0+dev-x86_64-lin.tar.gz"
},
"macos": {
"arm64": "https://github.com/raspberrypi/pico-sdk-tools/releases/download/v2.2.0-1/openocd-0.12.0+dev-arm64-mac.zip",
"x86_64": "https://github.com/raspberrypi/pico-sdk-tools/releases/download/v2.2.0-1/openocd-0.12.0+dev-x86_64-mac.zip"
},
"windows": {
"x64": "https://github.com/raspberrypi/pico-sdk-tools/releases/download/v2.2.0-1/openocd-0.12.0+dev-x64-win.zip"
}
}
},
// etc.
}
?

All this information can already be obtained using the GitHub API by just stepping backwards through versions to find the latest with the binary you need, so I'd be reluctant to add a separate JSON file which needs to be maintained.

Also, all versions since v2.1.1-2 have had all the binaries, and that is likely to be the case for future releases too (unless we need to do a release in under an hour, in which case we would skip the Risc-V toolchain build to speed up CI, and add a note to the release text like has been done in the past)

[lurch]

All this information can already be obtained using the GitHub API by just stepping backwards through versions to find the latest with the binary you need, so I'd be reluctant to add a separate JSON file which needs to be maintained.

My thought was that it'd be easier for some third-party installer-script to read a JSON file than it is to interrogate the GitHub API...

Also, all versions since v2.1.1-2 have had all the binaries, and that is likely to be the case for future releases too

...but if this is the case, then a separate latest.json file obviously becomes unnecessary 😃 (apologies to @thejpster that I over-complicated things!)

[thejpster]

By 'right place' I was alluding to platform differences regarding the usual home for executables. I agree it can go anywhere, but then I have to explain to users how to adjust their PATH appropriately.

If the extension works in Codium, that's perhaps an option. But it's a lot to install for someone who just wants to build and load a binary written in Rust.

What are the ties between picotool and the SDK? Is it the case that some versions of picotool might not work with code compiled against some versions of the SDK? Do I have to explain to users which version of picotool is appropriate for a given rp-hal version?

[will-v-pi]

What are the ties between picotool and the SDK? Is it the case that some versions of picotool might not work with code compiled against some versions of the SDK? Do I have to explain to users which version of picotool is appropriate for a given rp-hal version?

The SDK depends on picotool to create UF2 files (the old elf2uf2 was subsumed into picotool in 2.0.0), and also depends on it for RP2350 signing/hashing etc, so generally you should use the same SDK and picotool versions when building code to ensure compatibility of the command line arguments. Eg if you're using encrypted binaries with SDK <2.2.0, you need picotool <2.2.0, as that command line interface was changed to add better support in 2.2.0

When loading code (such as rust code), you should just use the latest version of picotool - there should be no compatibility issues with loading code compiled with an old SDK (or entirely different build system) using a newer picotool, and newer picotool has improvements to loading (eg speedups)

[will-v-pi]

By 'right place' I was alluding to platform differences regarding the usual home for executables. I agree it can go anywhere, but then I have to explain to users how to adjust their PATH appropriately.

Just note that the directory structure of these releases needs to be kept for the SDK to find them - ie a top picotool directory, containing the picotool binary and the picotoolXXX.cmake files. So users can't just take the picotool binary and put it in the PATH, else it won't work with the SDK, they have to take the whole picotool directory.

[thejpster]

ok, makes sense - except I guess our dependency is the encoding of the arguments to picotool load into our Rust configuration files.