{"id":284,"date":"2025-07-24T00:57:55","date_gmt":"2025-07-24T00:57:55","guid":{"rendered":"https:\/\/michael-stinger.com\/?p=284"},"modified":"2025-07-24T14:20:55","modified_gmt":"2025-07-24T14:20:55","slug":"a-cmake-strategy-for-the-pico-c-c-sdk","status":"publish","type":"post","link":"https:\/\/michael-stinger.com\/index.php\/2025\/07\/24\/a-cmake-strategy-for-the-pico-c-c-sdk\/","title":{"rendered":"A CMake Strategy for the Pico C\/C++ SDK"},"content":{"rendered":"\n

This article explores the challenges and strategies for adding support for CMake’s find_package()<\/code> mechanism to packages that depend on the Raspberry Pi Pico C\/C++ SDK. While the Pico SDK is designed for direct inclusion and does not export its library targets thereby barring directly adding find_package<\/code> support, I want to support modular, reusable components that abstract away platform-specific setup. The article analyzes common problems\u2014including missing export targets and toolchain configuration constraints\u2014and considers three implementation approaches for downstream dependency handling. The selected solution uses generator expressions to defer linking dependencies until the build stage, enabling find_package()<\/code> compatibility without duplicating toolchain logic or bloating downstream CMakeLists files. This is demonstrated through a real-world GARP Motor Controller HAL, with a flexible multi-toolchain build process via ExternalProject_Add<\/code>.<\/p>\n\n\n\n\n\n\n\n

Introduction<\/h2>\n\n\n\n

If you use CMake to define a target (say, a HAL) that links library targets from the Raspberry Pi Pico SDK and then attempt to export that HAL target to support CMake’s find_package<\/code>, CMake issues an error during the build stage:<\/p>\n\n\n\n

[build] CMake Error: install(EXPORT \"garp_mc_hal-rp2350Targets\" ...) includes target \"garp_mc_hal-rp2350\" which requires target \"pico_stdlib\" that is not in any export set.<\/code><\/p>\n\n\n\n

The issue is that the Pico SDK does not export it’s library targets as it expects users to have the SDK installed locally and available for linking, which isn’t entirely unreasonable given that compiling for the platform likely means you are actively using the ~$5 hardware. These Pico targets do conveniently register the include directories necessary for target use, and so would be nice to reuse if possible. Unfortunately, the SDK also does not support find_package<\/code> due to the way it configures the toolchain<\/a>. As an alternative to prescribing the --toolchain<\/code> argument at the command line, the SDK provides a .cmake file<\/a> that can be included to configure the toolchain, but then requires some CMake instructions introduced ahead of the project()<\/code> command. This .cmake<\/code> file has remained relatively stable since 2021<\/a>, but should be expected to change in the future. Given these factors, the typical workflow for building a project targeting the Pico hardware begins with installing the SDK onto the host system, specifying the PICO_SDK_PATH<\/code> environment variable. The project’s CMakeLists.txt<\/code> file then includes the pico_sdk_import.cmake<\/code> file, followed by the project()<\/code> command, and then the pico_sdk_init()<\/code> command. Downstream packages then would repeat this content in their CMakeLists.txt<\/code> files configuring the toolchain for each artifact. When using a HAL intended to abstract away the dependence on the SDK, this need to include the file and repeat these contents are less than ideal, and more importantly, the need to track which Pico library targets are used and explicitly add them to link lists is error-prone. As I’ve been developing a HAL and a series of motor controller applications, this latter has been particularly cumbersome.<\/p>\n\n\n\n

Use Case<\/h2>\n\n\n\n

Ideally, using the HAL would entail an opaque interface using find_package<\/code> and no other modifications to access the dependencies. More specifically, if writing an application A that leverages library L, in turn leveraging the HAL, the workflow would look something like this:<\/p>\n\n\n\n

    \n
  1. Application A’s CMakeLists.txt<\/code> would use find_package<\/code> to import the L library project<\/li>\n\n\n\n
  2. This would automatically introduce the L library’s linkages and other properties like header files<\/li>\n\n\n\n
  3. This, in turn, would automatically introduce the HAL’s dependencies, including the Pico SDK<\/li>\n<\/ol>\n\n\n\n

    The key elements here are the “automatic” steps that release me from trying to remember all of the appropriate dependencies two+ layers of dependencies back, and would make modularity significantly easier. The ability to build for multiple platforms (i.e. support multiple toolchains) from a single CMake entrypoint would also be a boon to simplify managing several independent but otherwise parallel directory structures.<\/p>\n\n\n\n

    Implementation<\/h2>\n\n\n\n

    To realize this pipe dream, a few options came to mind:<\/p>\n\n\n\n