Add the param for the pico sdk command argument.

[mklemarczyk]

In the OS that is not allowing to configure the ENV variables and case when using several different SDK versions, it would be preferable to be available to specify the command argument with the path to the SDK.

[lurch]

You didn't say which OS you're using, but on Linux you can do a 'one-liner' like:

$ PICO_SDK_PATH=../pico-sdk-1.4.0 ./pico_project.py --gui

[mklemarczyk]

I use, windows 11 and debian, depends on the day when I develop.
I was thinking on the way that this path will be got from the parameter and added into CMake file.

I am sorry. I am new to the project. My goal is to have new project with all SDK as git submodules.
I do not want to init all the stuff by hand each time. That is why I though about some param :)

I rarely use the same machine for coding, often my environment is inside docker container or remote environment.
It take time to setup it every time I switch.

[lurch]

The SDK-path is needed before the project-generator displays its GUI, because it uses the SDK to populate the list of available board-types https://github.com/raspberrypi/pico-project-generator/blob/master/pico_project.py#L1419 , and I don't think that would be possible if the SDK-path was itself a configurable parameter? (or it might be possible, but it'd probably be a bit tricky to add)

[mischievous]

Sorry, I am going to be blunt. Thats BS, sorry for being salty. You can easily have an arg to correctly configure the SDK path on the command line not using the bloody environment variables.

If I get bored I will add it in less than 2 hours while fixing these bugs...

1. You allow a path to the compiler to be specified, but in CheckPrerequisites is called before the path is set.

2. The the compiler path set from the command line is not used in CheckPrerequisites, so what's the bloody point?

3. The "PICO_TOOLCHAIN_PATH" should be set to the path of the toolchain.

4. The SDK version of pico_sdk_import.cmake should be the default unless the developer wants to customize it for some reason... But if they do not want to customize it the include should be "include(${PICO_SDK_PATH}/pico_sdk_import.cmake)" or change the "/" to "" because of windows.

5. There are a lot of other options for building that could be added, for instance "PICO_NO_UF2" will turn off the generation of the UF2 file. I use the picotool to load the images because it does not require me to reboot the board using the BOOTSEL as long as I had the UART I/O turned on and did not crash the board in a previous test.

[lurch]

You can easily have an arg to correctly configure the SDK path on the command line not using the bloody environment variables.

Yes, I was getting muddled up between "parameters specified on the command-line when launching pico-project-generator" and "parameters configured (at runtime) within the pico-project-generator GUI itself". Whoops.

[JamesH65]

Sorry, I am going to be blunt. Thats BS, sorry for being salty. You can easily have an arg to correctly configure the SDK path on the command line not using the bloody environment variables.

If I get bored I will add it in less than 2 hours while fixing these bugs...

1. You allow a path to the compiler to be specified, but in CheckPrerequisites is called before the path is set.
2. The the compiler path set from the command line is not used in CheckPrerequisites, so what's the bloody point?
3. The "PICO_TOOLCHAIN_PATH" should be set to the path of the toolchain.
4. The SDK version of pico_sdk_import.cmake should be the default unless the developer wants to customize it for some reason... But if they do not want to customize it the include should be "include(${PICO_SDK_PATH}/pico_sdk_import.cmake)" or change the "/" to "" because of windows.
5. There are a lot of other options for building that could be added, for instance "PICO_NO_UF2" will turn off the generation of the UF2 file. I use the picotool to load the images because it does not require me to reboot the board using the BOOTSEL as long as I had the UART I/O turned on and did not crash the board in a previous test.

I am happy to take PRs on the repo, unfortunately, I am a bit swamped at the moment, so it may take a while to review them.