Though Raspberry Pi might not agree I don't believe the toolchain has any real bearing on the VS Code Extension running on 32-bit.@hippy Well, all right then, it was an interesting attempt, and obviously the extension does not fit all ussrs. I do see how having an extension for most users very much helps RPi support the SDK and reduce the variables to that end. Unfortunately the ARM site just does not have a pre-built 32-bit toolchain for the amhf architecture.
If the extension were refactored, only downloaded and checked availability of tools, when asked to compile, it might fail then, but wouldn't need to fail for the project creation and related features. And it wouldn't need to fail on compile if it used what a user already had or downloaded an appropriate toolchain. The toolchain may stop the extension doing some of its thing, but that doesn't prevent the extension from being able to run on 32-bit, do things which shouldn't even need an SDK or toolchain installed.
I don't agree that having the Pico VS Code Extension makes it easier to support the SDK because doing things differently to how they suggest it should be done in Getting Started, how 'picosetup.sh' does things, creates two incompatible SDK regimes where they previously only had one, using different toolchains to what the VS Code Extension does.
The Sleep Pixies woke me up this morning with a better understanding of what's not right, how things would better be done, which would suit command line, VS Code and other IDE users equally well, including Windows users, in a consistent manner, which can use both SDK regimes and whatever toolchain is chosen transparently.
I have something like that already which I use but it's lacking things others would want to have. I never sat down and thought how it should be done, just dived in to have it do what I needed. So I'm off to adventure in that direction, see if I can do that more properly.
That was my fear, that it might mess up what I have working, with VS Code, on the command line and for other IDE.I plan to try the extension, but I already have bash shell scripts set up to do many things, and VSCodium is only my editor and my clangd server is picked up by it, and other GUI editors I have automatically use it, like Kate.
The good news is, as far as I can tell, the Pico SDK Extension doesn't interfere with the set-up and paths which you already have outside of VS Code. But it might have adverse consequences for any projects you use with it, but a backup, or only working on cloned copies, should mitigate that if it does.
Yes, it was more being able to set them as easily as using CMake Tools. That has a 'build:[Release/Debug/MinSelRel/etc]' option in the system bar which allows two-click configuration. Something similar which allows selecting board and other variant info and adjusting the build directory as appropriate would be ideal for me.EDIT: As far as VSCode, it appears the kits feature is a nice way to set up different build types. You can add custom kits for flash, no flash, and copy to RAM then select them as needed. You can set up multiple kits in the .vscode/cmake-kits.json file.
What I am now thinking of is a command line tool which can do everything the extension does, with access via a textual graphics interface, a native graphical UI, browser access, callable from a VS Code Extension and other IDE. I might not be able to create all those myself but it should be easy for those with appropriate skills to do so. It's having the correct framework to do what is required which is the foundation to it all.
Statistics: Posted by hippy — Wed Nov 20, 2024 12:47 pm