-
-
Notifications
You must be signed in to change notification settings - Fork 372
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use of {runtime.platform.path}
makes referencing other cores often impossible
#2616
Comments
Proposal:
Also fix this inconsistency:
This means
|
@egnor thank you very much for the valuable bug report. Can you provide a POC core that references an esp32/pico core (to demonstrate the issue)? |
{runtime.platform.path}
makes referencing other cores often impossible
(will do, stay tuned!) |
OK here's a minimal example: https://github.com/egnor/repro_arduino_cli_2616
There's a
(I'm ignoring the The (I think there might also be an issue with I have found by experience if I fudge my way through this particular issue, there are many others, as |
Thanks @egnor
I'm sure that many other definitions are missing. I'm also concerned this system could be fragile since a change in the esp32 platform.txt (variable names, or how they are used...) could lead to a breaking change in the platforms that use esp32 as a reference. |
This is exciting @cmaglie !! You're right, while the platform is referenced, nothing about the board definition is. I have updated my repo (https://github.com/egnor/repro_arduino_cli_2616) accordingly:
You can see if that works? I'm going to try to pull down your PR branch and see if it's easy for me to build. As far as fragility based on the platform definition -- a certain amount of that is inevitable with configuration extension like this BUT I agree that it feels like a lot of duplication. (Less, at least, than forking the entire platform!) I would propose some mechanism for "inheriting" one board definition from another, which I think is outside the scope of this particular piece of work. (It should be simpler than core reuse, since boards don't have associated assets, it's just a matter of copying all the key values and then overriding.) |
I also had to make sure to reference the variant externally:
having done so 🎉 it works 🎉 using your PR branch!
or at least the compile succeeded, I haven't tried running it on a board, but I think this is most of the way for sure! I am excited to see this PR land, it will be a great step forward. (And then we can get board-to-board inheritance... and maybe some way to reference local index and/or package files without hitting a public URL... and standardize on some way to add compiler defines... then we're golden!!) |
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'sboards.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-esp32platform.txt
file does this sort of thingMany of the uses are deep in long, complex operations one wouldn't want to cut-and-paste:
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
The text was updated successfully, but these errors were encountered: