Stop searching for `pico-sdk-tools-config.cmake` during configure step

[zbynekwinkler]

During configure step there is a really long time spent with mbedtls available at ... as a last line of output. I have measured the time by piping cmake output to ts and I see time around 12 minutes. I have taken strace look while wating and it seems it is searching the directories in my path for pico-sdk-toolsConfig.cmake and pico-sdk-tools-config.cmake but somehow doing it quite slowly.

I am running this inside debian bookworm under WSL so there are a lot of directories spilled over from Windows. When I remove them from path, the same step takes 10s (which is still a lot since the total time is 14s).

There are no such files anywhere and it works without them just fine. So it would be nice if the search for them could be somehow skipped.

$ cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=1 -DPICO_SDK_PATH=~/pico-sdk . 2>&1 | ts
Oct 23 21:37:12 PICO_SDK_PATH is /home/zbynek/pico-sdk
Oct 23 21:37:12 Defaulting PICO_PLATFORM to rp2040 since not specified.
Oct 23 21:37:12 Defaulting PICO platform compiler to pico_arm_gcc since not specified.
Oct 23 21:37:12 -- Defaulting build type to 'Release' since not specified.
Oct 23 21:37:12 PICO compiler is pico_arm_gcc
Oct 23 21:37:12 -- The C compiler identification is GNU 12.2.1
Oct 23 21:37:17 -- The CXX compiler identification is GNU 12.2.1
Oct 23 21:37:22 -- The ASM compiler identification is GNU
Oct 23 21:37:26 -- Found assembler: /usr/bin/arm-none-eabi-gcc
Oct 23 21:37:26 -- Detecting C compiler ABI info
Oct 23 21:37:27 -- Detecting C compiler ABI info - done
Oct 23 21:37:27 -- Check for working C compiler: /usr/bin/arm-none-eabi-gcc - skipped
Oct 23 21:37:27 -- Detecting C compile features
Oct 23 21:37:27 -- Detecting C compile features - done
Oct 23 21:37:27 -- Detecting CXX compiler ABI info
Oct 23 21:37:27 -- Detecting CXX compiler ABI info - done
Oct 23 21:37:27 -- Check for working CXX compiler: /usr/bin/arm-none-eabi-g++ - skipped
Oct 23 21:37:27 -- Detecting CXX compile features
Oct 23 21:37:27 -- Detecting CXX compile features - done
Oct 23 21:37:27 Build type is Release
Oct 23 21:37:27 Defaulting PICO target board to pico since not specified.
Oct 23 21:37:27 Using board configuration from /home/zbynek/pico-sdk/src/boards/include/boards/pico.h
Oct 23 21:37:28 -- Found Python3: /usr/bin/python3 (found version "3.11.2") found components: Interpreter
Oct 23 21:37:28 TinyUSB available at /home/zbynek/pico-sdk/lib/tinyusb/src/portable/raspberrypi/rp2040; enabling build support for USB.
Oct 23 21:37:28 BTstack available at /home/zbynek/pico-sdk/lib/btstack
Oct 23 21:37:28 cyw43-driver available at /home/zbynek/pico-sdk/lib/cyw43-driver
Oct 23 21:37:33 Pico W Bluetooth build support available.
Oct 23 21:37:33 lwIP available at /home/zbynek/pico-sdk/lib/lwip
Oct 23 21:37:33 mbedtls available at /home/zbynek/pico-sdk/lib/mbedtls
Oct 23 21:49:19 Skipping TinyUSB dual examples, as TinyUSB hw/mcu/raspberry_pi/Pico-PIO-USB submodule unavailable
Oct 23 21:49:24 -- Configuring done
Oct 23 21:49:30 -- Generating done
Oct 23 21:49:30 -- Build files have been written to: /home/zbynek/pico-examples

[zbynekwinkler]

I forgot to mention that I am configuring pico-examples repository.

Looking at

• #1403

it seems it is not working for me. Using the --trace-expand option I see it is searching for uf2 again and again. Sure enough, when I add message inside the if

https://github.com/raspberrypi/pico-sdk/blob/6a7db34ff63345a7badec79ebea3aaef1712f374/tools/CMakeLists.txt#L64-L70

my screen is flooded with it (cmake version 3.25.1).

[ndabas]

We're using this on Windows to find pre-compiled binaries for pioasm and elf2uf2 -- just dropping a comment here so that I am in the loop on what resolution comes up, and if we need to make changes to the Windows installer for that to work.

[ndabas]

I think a workaround might be to set CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH to FALSE to stop it from scanning everything in the system PATH. Not sure if that will interfere with the compiler detection code though.

We could pass NO_SYSTEM_ENVIRONMENT_PATH to the find_package calls in the SDK, but it feels like it shouldn't be something we need to configure in our own code.