Open jcar87 opened 4 months ago
Assuming that the CMakeLists is configured like documented here: https://github.com/raspberrypi/pico-sdk/tree/master, with a pico_sdk_import.cmake
included as part of the consumer project:
cmake_minimum_required(VERSION 3.13)
# initialize the SDK based on PICO_SDK_PATH
# note: this must happen before project()
include(pico_sdk_import.cmake)
project(my_project)
# initialize the Raspberry Pi Pico SDK
pico_sdk_init()
# rest of your project
Once the path to the SDK is located, I suspect it eventually set this as the CMAKE_TOOLCHAIN_FILE
:
https://github.com/raspberrypi/pico-sdk/blob/6a7db34ff63345a7badec79ebea3aaef1712f374/cmake/preload/toolchains/pico_arm_gcc.cmake
but since it's already set by Conan upon invoking CMake, then it is skipped - and some mismatched configuration happens.
Once the path to the SDK is located, I suspect it eventually set this as the
CMAKE_TOOLCHAIN_FILE
: https://github.com/raspberrypi/pico-sdk/blob/6a7db34ff63345a7badec79ebea3aaef1712f374/cmake/preload/toolchains/pico_arm_gcc.cmakebut since it's already set by Conan upon invoking CMake, then it is skipped - and some mismatched configuration happens.
Yes, that is the problem I think.
My initial thoughts were that I might need to create a custom Toolchain for this, but I have no idea on how to do this for the SDK.
Here is a somewhat minimal example on what our CMakeLists look like in our RP2040 projects:
And here is a somewhat minimal conanfile.py
that goes along with that:
There are two Conan features where you can override the behaviour of the Conan-generated toolchain:
tools.cmake.cmaketoolchain:toolchain_file
: this will instruct Conan to skip the generation of its default CMake toolchain, and just pass whichever file you tell it to instead.tools.cmake.cmaketoolchain:user_toolchain
: this will still load the Conan-generated CMake toolchain, but it will "chain load" the contents of this file You can pass this either:
-c tools.cmake.cmaketoolchain:toolchain_file=/path/to/toolchain.cmake
[conf]
section of your profile filepackage_info()
of a recipe that contains the SDK (in case that applies here)I've added tools.cmake.cmaketoolchain:user_toolchain
to the profile, but the behavior shows additional failures due to apparanent misconfigurations:
I have these lines in the CMakeLists in an attempt to circumvent compiler-check errors
set(CMAKE_C_COMPILER_WORKS 1)
set(CMAKE_CXX_COMPILER_WORKS 1)
But it doesn't work that way, as seen in the above build error.
Without the COMPILER_WORKS circumvention, I get the following:
I suspect I have a similar error as described here: https://github.com/raspberrypi/pico-sdk/issues/1597#issuecomment-1873435498
Apparently, some parts (like ELF2UF2) require a native compiler and not the arm-none-eabi
cross-compiler.
Allthough I have commented out the usage of the additional outputs, I believe that the error is related to the pico_sdk only getting the compiler configuration defined in conan and this might not work for all cases.
I believe somehow this behaviour of using a different compiler for a necessary tool used in the Pico SDK is broken when using Conan, but when building normally it gets resolved fine.
TBH, I very much hate this about the SDK structure, I believe there shouldn't be any hidden/embedded tools like this in the build-process.
I've read a little bit through an issue and neither elf2uf2
nor pioasm
should be needed as long as I don't use the corresponding function. Which brings me back to zero, since I don't use both in my minimal example, yet they are used?
I should mention, I do not mind having to compile the SDK with the project, my problem solely lies in the face that it does not compile when run through conan due to misconfigurations occuring with conan_toolchain.cmake
.
As a note, the build does work without conan:
(This regular build requires the native compiler for pioasm
which links to an elf
file)
According to https://github.com/raspberrypi/pico-sdk/issues/1693#issuecomment-2090985744 I can get rid of the errors caused by pioasm
and elf2uf2
forcing pre-compiled binaries with the described CMake snippet.
I then skip the simple test program
error again using set(CMAKE_C_COMPILER_WORKS 1)
and set(CMAKE_CXX_COMPILER_WORKS 1)
.
The end result is further build errors, and I'm at a loss at this point why the compilation with Conan produces all of these errors, which do not occur without it.
From my perspective, I've checked these boxes:
arm-none-eabi
pico_sdk_import.cmake
I then suspected there's further misconfiguration regarding the architecture, since these errors are weird and the architecture "normally" is configured when using pico_sdk_import.cmake
and then calling pico_sdk_init()
in the CMakeLists.
However that doesn't seem to be the case when using conan, so I've manually configured some flags in the profile:
[conf]
tools.cmake.cmaketoolchain:user_toolchain=["$ENV{PICO_SDK_PATH}/external/pico_sdk_import.cmake"]
tools.build:cflags=["-mcpu=cortex-m0plus", "-mthumb", "-march=armv6-m"]
tools.build:cxxflags=["-mcpu=cortex-m0plus -mthumb", "-march=armv6-m"]
And all of a sudden, we see this:
Main issue is solved, but my question remains:
What the hell does conan do differently that these things are not configured, EVEN THOUGH they should be when pico_sdk_init()
is used in my CMakeLists.txt
and the toolchain is imported using the suggested user_toolchain
?
What is your question?
From: https://cpplang.slack.com/archives/C41CWV9HA/p1714639717500339
Profile:
Results in error:
Have you read the CONTRIBUTING guide?