compile_time_choice.S fails to build when using PICO_CONFIG_RTOS_ADAPTER_HEADER

[NomiChirps]

The PICO_CONFIG_RTOS_ADAPTER_HEADER define, introduced in #851, will cause src/common/pico_base/include/pico/config.h to include the named file. When that pico/config.h is included from src/common/pico_base/include/pico.h, this works fine.

However, boot_stage2/compile_time_choice.S includes boot_stage2/include/config.h, which includes pico/config.h DIRECTLY. This means that the __PICO_XSTRING() macros aren't defined and preprocessing fails.

I ran into this issue while using https://github.com/dfr/rules_pico to build the SDK, but from my reading of the CMake files here, I don't see how it would work for a regular build either.

[kilograham]

boot_stage2 build in the SDK does not link against FreeRTOS-Kernel and so would not include this define (so i'd say to that extent this is a bug in rules_pico)

There is a bug to fix that boot_stage2 should include the full pico config chain now which is assembly safe

[NomiChirps]

Yeah, that's fair. In rules_pico that define is associated with pico/config.h and gets propagated transitively to everything that depends on it, rather than being associated with the FreeRTOS library. I think it's still worth supporting this for consistency's sake, so that different compilation units aren't using different versions of the config (even if it makes no difference in this case).

Thanks for accepting this issue!

[dfr]

Thanks for taking a look at this. Let me know if this is better addressed in rules_pico rather than in the SDK.

[mordae]

I am confused by the above discussion.

I have decided to hook into these macros for compatibility with a simple home-grown task scheduler and the build fails with:

pico-sdk/src/common/pico_base/include/pico/config.h:23:10: error: #include expects "FILENAME" or <FILENAME>
   23 | #include __PICO_XSTRING(PICO_CONFIG_RTOS_ADAPTER_HEADER)
      |          ^~~~~~~~~~~~~~

Build works fine when I modify the pico/config.h header to include pico.h first. I ifndef __ASSEMBLER__ inside the extra header.

I feel this needs a little bit better user story but I have not dived deep enough into the SDK to be able to think up a proper solution.

[kilograham]

fix merged into develop