Skip to content

Use of {runtime.platform.path} makes referencing other cores often impossible #2616

Closed
@egnor

Description

@egnor

Describe the problem

(I found this issue discussed various places, but no specific open bug for the problem? I would be delighted to get a pointer if I missed something.)

The ability to reference other cores from a platform seems to be an important design feature, and it is the recommended way to create custom boards.txt entries without having to stuff every board ever made into the platform vendor's boards.txt file.

HOWEVER, in practice, for many platforms (including very popular ones like rp2040 and esp32), this referencing doesn't work. The reason is that those platform definitions reference {runtime.platform.path} heavily. For example, the arduino-esp32 platform.txt file does this sort of thing

...
tools.esp32-arduino-libs.path={runtime.platform.path}/tools/esp32-arduino-libs
...
compiler.sdk.path={tools.esp32-arduino-libs.path}/{build.mcu}
...
compiler.cpreprocessor.flags="@{compiler.sdk.path}/flags/defines" "-I{build.source.path}" -iprefix "{compiler.sdk.path}/include/" "@{compiler.sdk.path}/flags/includes" "-I{compiler.sdk.path}/{build.memory_type}/include"
...

Many of the uses are deep in long, complex operations one wouldn't want to cut-and-paste:

recipe.hooks.prebuild.4.pattern=bash -c "[ -f "{build.source.path}"/bootloader.bin ] && cp -f "{build.source.path}"/bootloader.bin "{build.path}"/{build.project_name}.bootloader.bin || ( [ -f "{build.variant.path}"/{build.custom_bootloader}.bin ] && cp "{build.variant.path}"/{build.custom_bootloader}.bin "{build.path}"/{build.project_name}.bootloader.bin || cp -f "{runtime.platform.path}"/tools/sdk/{build.mcu}/bin/bootloader_{build.boot}_{build.boot_freq}.bin "{build.path}"/{build.project_name}.bootloader.bin )"

One might say this is a bug in arduino-esp32 (and arduino-pico, and...), and they should use {build.core.path} instead. And maybe so-- but if they do, their platform.txt becomes incompatible with older versions of Arduino, e.g. before #1012 was fixed.

Speaking of #1012, the discussion there points to use of symlinks as a workaround, but that's clearly messy, difficult, fragile, and hard to automate. There's also discussion of this issue in esp8266/Arduino#5769 (ESP8266) and espressif/arduino-esp32#4691 (ESP32). (From those discussions, it would be great if {build.core.platform.path} was available to avoid needing to use {build.core.path}/../.. if trying to work with this.)

Until this is solved, external core reference and all the reuse it was supposed to enable is basically broken.

To reproduce

Attempt to reference another core from a simple boards-only platform definition, as recommended in various places

Expected behavior

Core reference works, code builds and uploads

Arduino CLI version

arduino-cli Version: 0.35.3 Commit: 95cfd65 Date: 2024-02-19T13:24:24Z

Operating system

N/A

Operating system version

All

Additional context

No response

Issue checklist

  • I searched for previous reports in the issue tracker
  • I verified the problem still occurs when using the nightly build
  • My report contains all necessary details

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions