-
-
Notifications
You must be signed in to change notification settings - Fork 7k
Test json-aware builder #5197
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
Test json-aware builder #5197
Conversation
✅ Build completed. Please test this code using one of the following: ⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-5197-BUILD-583-linux32.tar.xz ℹ️ The |
Are you sure it's a good idea to put this into the builder, rather than have the IDE which already manages platform stuff simply tell the builder which toolchain to use? |
Already there's quite a lot of redundant stuff between the builder and the IDE which must be maintained perfectly in sync to avoid bugs. For example, which libraries are actually used needs to track perfectly between the IDE's File > Examples & Sketch > Include Library and what the builder will actually use when it compiles the sketch. To illustrate the fragile nature of this situation, I believe a bug was recently added by the change to also use the library.properties architecture to alter the platform vs builtin vs sketchbook library precedence. The corresponding change wasn't made on the IDE side in how libraries are actually presented to the user by the GUI. (eventually I'll isolate this better and submit an issue with reproducible test cases, but that's going to take some time) Duplicating this sort of subtle platform dependency stuff might require much more long-term maintenance to keep the IDE and builder using an identical set of criteria. I fear this might be making the whole system much more brittle in the long run... |
Hi Paul, IMO, the oversimplified logic behind a lot of decisions that the IDE takes is not ready for a world with continuous updates and deployments. Small specialised tools would make the difference here, leaving the gui simple to code and to extend (which is the great advantage of Java) In the long term, a collection of standalone tools (the builder, the uploader, the library crawler) which cooperate could fit better the great variety of situations the IDE needs to solve correctly. For example, the library indexer could use specific OS notify methods (I'm thinking about https://fsnotify.org/) to cache the library resolution and provide snappy results. The IDE and the builder would benefit from this offload without any code duplication. This long term strategy needs a lot of effort which we can't spend right now because the toolchain bug must be solved really soon. @cmaglie is also coding a Java only solution to address it so we can choose which solution fits better |
I agree, a fix is needed urgently. |
The last thing I want to do is act act an obstacle. Hopefully later there'll be an opportunity to consider the overall design.... |
Your contribution is invaluable so you will never be an obstacle, quite the opposite 😄 . Once the "crisis" is over we'll surely reconsider the design to make everyone happy and less bug prone |
Superseded by #5199 (better, faster and non hacky solution). Closing this while leaving arduino/arduino-builder#173 open but freezed |
No description provided.