work around panic: no major version found in arduino 1.8.14+

[ObviousInRetrospect]

this is a know bug with a trivial workaround that would get rid of the need to recommend against 1.8.19. I suspect the ratio of frustration saved to the indignity of workarounds to known bugs probably is justified in this case.

[SpenceKonde]

Thanks, Ugh I was praying that It wouldn't be this that needed to be changed. I could just never manage to get the versions to match before I started doing that,, I wasn't able to maintain a consistent version within a release, I had to have it in one place and construct the other forms from that, otherwise I'd forget to update one of them and the versions would not be self-consistent.

[ObviousInRetrospect]

hmm what about using preprocessor concatenation to cause a #error if they mismatch - either in a specific test sketch or in pins_arduino or something? [edit: not actually convinced this works. tried adding -DMEGATINYCORE_COMPOSITE="{versionnum.major}.{versionnum.minor}.{versionnum.patch}{versionnum.postfix}" to build.versiondefines and remembered you can't compare strings in an #if]

or a GitHub action based consistency test?

alternately, given that you now generate boards.txt in python, is it worth extending that to update this line? is there a release prep script (moral equivalent of autoreconf preparation)?

with the last "hourly" build of the 1.x ide series being from April I am not optimistic on this getting fixed

[ObviousInRetrospect]

another path might be to change a pair of recipes in platform.txt and have one use the version and the other use {versionnum.major}.{versionnum.minor}.{versionnum.patch}{versionnum.postfix} to construct a path such that builds will fail if they mismatch. or an explicit invocation of "/bin/test" or the windows equivalent.

[ObviousInRetrospect]

filed arduino/Arduino#11813 but not optimistic and think if there isn't traction on fixing it by the release doing the less elegant thing is better for the users of the cores than telling them to run a version with known severe security problems.

[SpenceKonde]

The reason I went to that is that I never once managed to do a release without fucking up the number some how. I can't make wire compile, I can''t handle versions, my clients board came back and is totally busted and needs major changes..... the politics of my home country is a disgrace.

[ObviousInRetrospect]

#include <TheMerryMinuet.song>

[SpenceKonde]

The boards.txt generator extension method sounds like the best course of action

…

____________ 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 Thu, Aug 11, 2022, 08:25 ObviousInRetrospect ***@***.***> wrote: hmm what about using preprocessor concatenation to cause a #error if they mismatch - either in a specific test sketch or in pins_arduino or something? alternately, given that you now generate boards.txt in python, is it worth extending that to update this line? with the last "hourly" build of the 1.x ide series being from April I am not optimistic on this getting fixed — Reply to this email directly, view it on GitHub <#763 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEW4ATO3U3KHXRZGRLR3VYTWKXANCNFSM56GQLNRA> . You are receiving this because you commented.Message ID: ***@***.***>

[SpenceKonde]

Closing this pull request for reasons described above