-
-
Notifications
You must be signed in to change notification settings - Fork 398
Unique property definitions from previous compilations for other custom board options persist #1614
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
Comments
So I just spent tens of hours debugging a clock fuse issue caused by the defect described here: https://forum.arduino.cc/t/problems-with-megatinycore-in-ide-2/959081 which links to this bug. This probably should be a far higher severity. It causes incorrect fuse settings which in some cases can brick the hardware. This does not occur on 1.x |
For what its worth, the maintainer of megaTinyCore (https://github.com/SpenceKonde/megaTinyCore) just added: WARNING: NOT COMPATIBLE WITH 2.0.x version of the IDE due to critical regressions. These bugs in the IDE prevent board settings from being correctly recognized. Please direct your complaints to the Arduino team. We do not intend to make any effort to support working around the errors of the arduino team in beta software. Working around it in released versions is hard enough. If and when the third party hardware is ammededed with a clear description of the intended behavior, I will fix it. I am not going to fix or allow fixes for bugs thare aren't even acknowledged by the Arduino team as such and may or may not be considerered intended. to the top of his documentation. |
I consider this issue to be show stopper as far as ATTinyCore, DxCore and megaTinyCore are concerned. A workaound wouldr require hundreds or thousands of lines added to boardst .txt. Those three cores do not and never will support any IDE version with such a severe bug with such a challenging workaround. |
@per1234, you reported this bug and documented reproduction using the IDE 2.0 and the grpc interface only. Does that mean the issue does not occur when using the commandline |
Correct. It is specific to the "daemon" mode because there you have a persistent instance which can be used to do multiple compilations for various boards.
That is correct. |
Seems like 2.0.0 is nowhere ready for release with so many serious bugs...
…____________
Spence Konde
Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy
GitHub: github.com/SpenceKonde
ATTinyCore: Arduino support for almost every ATTiny microcontroller
Contact: ***@***.***
On Mon, Aug 1, 2022, 06:42 Matthijs Kooijman ***@***.***> wrote:
@per1234 <https://github.com/per1234>, you reported this bug and
documented reproduction using the IDE 2.0 and the grpc interface only. Does
that mean the issue does *not* occur when using the commandline arduino-cli
verify? I guess that makes sense, since then you have a clean arduino-cli
start and it would be hard for anything from a previous build to leak into
a subsequent build, but for the grpc interface (which is also used by IDE
2.0 I think), that could be a matter of not clearing any previous options
(maybe the implementation just applies any custom options when selected,
instead of restarting with a clean slate?)
—
Reply to this email directly, view it on GitHub
<#1614 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTXEW54ZCXPVR3COF3TUYDVW6SZNANCNFSM5LI37MTA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Thanks for fixing this! I went ahead and reproduced the issue in RC9.1 and then confirmed that dropping the 08/03 nightly cli build into /Applications/Arduino IDE.app/Contents//Resources/app/node_modules/arduino-ide-extension/build fixes the issue. Since I assume the nightly builds on the IDE side pick up the configured cli release rather than the nightly it might be worth pushing out a cli release that includes it soonish so the nightly builds on the ide side can get the fix. |
Thanks for the feedback @ObviousInRetrospect!
that's correct, we pin a specific commit of the Arduino CLI to avoid breaking changes in the gRPC API, but we can manually move the pinned version to the current master: arduino/arduino-ide#1280 as soon as the CI passes you will have an Arduino IDE 2.x nightly with the fix. |
…ests in go (WIP) (arduino#1806) * testsuite: Added helper functions to handle test envs * testsuite: Added helper functions to run arduino-cli * testsuite: Added colored output to arduino-cli Run helper * testsuite: Pass cli config through env variables * testsuite: added env commands to download and extract files * testsuite: added commands to start cli daemon and run some gRPC calls * testsuite: moved test harness inside 'internal' package * testsuite: added first daemon test for gRPC board watch * testsuite: added http server helper * testsuite: added JSON helpers * testsuite: Added possibility to use shared download staging folder * testsuite: Converted a core_test.py test (WIP) * REMOVEME: Deactivate daemon integration test for now * testsuite: force colored output * testsuite: moved all generic subroutines into their own library * testsuite: moved daemon test in his own dir * fixed typo * testsuite: added some helpers to improve daemon testing * testsuite: added test for arduino#1614 * Removed converted test * testsuite: perform build before test Otherwise people running the task locally will have a bad time when the test either fails due to the missing executable, or far worse when they get incorrect test results because they don't realize it is using whichever random executable happened to be sitting around from the last time they did a build. * Added missing comment * Renamed test file * Skip failing tests * Updated licensed cache * re-enable test for fixed bug * testsuite: disable postinstall Otherwise Windows CI will get stuck. * Removed useless startDaemon * Renamed inst -> grpcInst * Close daemon gRPC connection on test cleanup * Added comment * Apply suggestions from code review Co-authored-by: per1234 <[email protected]> * Update internal/integrationtest/arduino-cli.go Co-authored-by: per1234 <[email protected]> Co-authored-by: per1234 <[email protected]>
Describe the bug
The Arduino boards platform system offers a custom board options capability. The platform properties associated with a given option are defined only when that option is selected (e.g.,
arduino:avr:nano:cpu=atmega328old
or Tools > Processor > ATmega328P (Old Bootloader)).Because the properties defined in
boards.txt
override those inplatform.txt
, default property definitions are often made inplatform.txt
. This allows non-default property definitions to be made only for those board configurations that need it. A prominent example of this practice is thebuild.extra_flags
property (e.g., here).🐛 If a property was defined in a custom board option of a board previously compiled for, that board option associated definition persists into subsequent compilations with another board option selection that does not define the property.
To Reproduce
Set up
Download this
boards.local.txt
file: boards.local.txtThis file defines a
some_menu
custom board option for thearduino:avr:uno
board.Click to see file contents
Put the
boards.local.txt
file in thearduino:avr
boards platform installation folder (e.g.,~/.arduino15/packages/arduino/hardware/avr/1.8.4/
)Demo for Arduino IDE 2.x
https://github.com/arduino/arduino-ide/issues/591
)(This is done only so you can see the flags added to the compilation commands by the custom board option properties.)
🐛 Compilation fails unexpectedly:
Note that the flag that caused the compilation failure is only defined via the
build.extra_flags
property of the Tools > Some Custom Menu > Bad Option custom board option. The expected behavior would be that the default empty property definition fromplatform.txt
be used instead.Note that the compilation commands do contain the expected
-DGOOD_COMPILER_CPP_EXTRA_FLAGS
flag which was defined via thecompiler.cpp.extra_flags
property of the Tools > Some Custom Menu > Good Option custom board option, which proves that option was used:This behavior is extra confusing since the erroneous property definition could only have been produced by a compilation for the Tools > Some Custom Menu > Bad Option custom board option, but no compilation was initiated for that option in this demo. The explanation is that the Arduino IDE automatically compiled for that option as soon as you selected the Arduino Uno board in order to generate the language server data.
Demo for Arduino CLI
arduino-cli sketch new
) forarduino:avr:uno:some_menu=bad
🙂 The compilation fails as expected due to the invalid compiler flags specified by this board option configuration:
arduino:avr:uno:some_menu=good
🐛 Compilation fails unexpectedly:
Expected behavior
Property definitions from previous compilations should not be persistent.
Desktop
Additional context
Originally reported at https://forum.arduino.cc/t/stm32f-board-will-not-select/941102
Although I demonstrated the issue via a minimal contrived platform configuration, the report was from a user of the
STMicroelectronics:stm32
("STM32Duino") boards platform, which provides a real world occurrence of this bug. You can reproduce it using that platform via the following instructions:Click to see instructions
(this is necessary due to the unrelated bug
https://github.com/arduino/arduino-ide/issues/637
)(This particular board configuration is selected arbitrarily for the demo. Other board configurations in this platform are also affected by the bug.)
🐛 Compilation fails unexpectedly:
This error is caused by a property definition from another option of the "Board part number" menu than the "Generic F401CCYx" option that was selected:
https://github.com/stm32duino/Arduino_Core_STM32/blob/2.2.0/boards.txt#L2117
The "Generic F401CCYx" option that was selected does not define the property:
https://github.com/stm32duino/Arduino_Core_STM32/blob/2.2.0/boards.txt#L2270-L2276
so the default definition should have been used:
https://github.com/stm32duino/Arduino_Core_STM32/blob/2.2.0/platform.txt#L56
Another sighting of this bug here:
https://forum.arduino.cc/t/problems-with-megatinycore-in-ide-2/959081
The text was updated successfully, but these errors were encountered: