-
Notifications
You must be signed in to change notification settings - Fork 13.3k
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
esp8266 Arduino package can't be used as referenced package #5769
Comments
the PR did not solve it. the solution was to use other option is to do the replace as part of release preparation |
@d-a-v David, after the new release I again try to solve the "referred package" issue. The main problem are paths to the So if the note*: there is a new problem in 2.5.1. the
doesn't evaluate anything else then the problematic arduino-sam package (Due) uses the system folder https://github.com/arduino/ArduinoCore-sam/tree/master/system |
@JAndrassy I suspect this isn't an issue with wide impact, so you're the main interested party. You started a proposal with #5770, but then dropped it, and it's not clear to me why. Will you be continuing your work, or should this issue just be closed? |
the maintainers should be interested, because now every manufacturer of a esp8266 board must add the board to this package and can't maintain own board definitions. it is hard to work on this if the platform.txt file changes so much like in last months. would the maintainers accept renaming of the |
@JAndrassy please make your proposal in a PR, or update #5770. We can discuss further there. |
I would need a release version of the current platform.txt. How is it transformed for release? |
Only |
no. there is some edit not tracked in git. tools removed, paths of tools changed and this line was removed in packaged platform.txt in 2.5.2
|
You are right, sorry. |
So when I opened this issue, esptool was installed as IDE tool, next to mkspiffs and xtensa-lx106-elf-gcc. But then the upload tool changed and is with SDK in tools folder next to core folder. And this path can't be used from a referring package to run commands, because there is no build variable which would evaluate to this path for a command. That is why my PR to solve the referring of the package failed. So first thing to solve would be to make the upload.py & co installable as IDE tool like mkspiffs or the old esptool. |
Of course the problem with the build variables evaluation at Upload is a problem of the Arduino IDE. I investigated it and reported it in May but then new version of IDE doesn't have it fixed. @earlephilhower please could the py scripts from tools folder be 'external' tools in boards manager package (like the old esptool was or mkspiffs is)? |
@JAndrassy is that what you need achieved by |
One gotcha I see here is if @JAndrassy does move @JAndrassy, the |
sorry for the confusion. the renaming of Before the old esptool was replaced with the esptool.py wrapped in upload.py, I made the PR which changed the paths in platform.txt to use other variable then {runtime.platform.path}. But in the same time as I made the PR the esptool was replaced and the change in my PR was not solving the path for upload.py. (the espota.py had the problem too, but for that I could document a workaround for referred packages.) Arduino builder enables to create boards packages or custom board definitions which refer core and tools of some other boards package. This was made to avoid copies of complete board packages for definition of board variants. Here I have examples of custom boards definitions referring AVR and SAMD boards packages. And here is example of Sparkfun AVR boards package which refers the Arduino AVR package. Only board variants are defined. The core and tools are from the Arduino package. The problem with esp8266 boards package as referred is the use of {runtime.platform.path} to evaluate the tools folder. The {runtime.platform.path} evaluates to referring package, not to referred where the tools folder is. I attempted to replace it with I want to solve it only for Boards Manager installed package, not for 'git install'. |
I think @JAndrassy has a point here, but I'm not sure what the underlying issue is or how to go about fixing is now. Marking for 3.0.0 |
first step is to make upload.py and espota as tools installed in it is not a requirement of the Arduino IDE, but a workaround for a 'feature' (old bug?). the Arduino IDE can't access them in the current location |
Do you have, or can you make a sample of what a referred package would be using the 8266 core? I'm thinking of something to test against as the tweaks are done. (i.e. it fails now, but when the core is in some "good" state it magically starts working again) GOOG doesn't give anything on the Arduino site about it (maybe I'm using the wrong term), so I really don't know what kind of spec we're working towards. |
a simple example is a custom boards definition like this one the link to specification is in platform.txt at the top |
platform specification has moved to https://arduino.github.io/arduino-cli/0.23/platform-specification/ |
@JAndrassy
On a linux installation, both point to the same location. |
it is not the same location if 'board platform' is different from 'core platform'
no. because there is a second problem: esptool.py and espota.py don't work from different 'board platform', because Arduino IDE upload doesn't have build.core.path (and build.system.path) evaluated (arduino/arduino-cli#1012). (Upload tools shouldn't be at that location. They should be installed as 'global' tools like the old esptool was, back then when I made the first PR about this. In esp32 core esptool,py is installed as 'global' tool) a first good step would be to rename /tools folder to /system and use |
@JAndrassy Do you plan to propose a PR for this ? (that you you have been able to test with your global use-case) |
Arduino IDE 3rd party Hardware specification section "Referencing another core, variant or tool" specifies that a boards package can be referred from custom hardware definitions or other boards packages.
esp8266 package can't be used now as referred, because platform.txt file entries use variable {runtime.platform.path}, which points to the folder of selected board's boards.txt file. In case of a referring definition it is not the right folder to access sdk and tools.
solved in PR #5770
The text was updated successfully, but these errors were encountered: