Core 2.0.18 gives compile errors in IDE2 and How to solve

Official Hardware Nano Family Nano ESP32
1

If core 2.0.18 in installed sketches fail to compile in IDE2 but will compile in IDE1

In this folder
c:\Users\abcde\AppData\Local\Arduino15\packages\arduino\hardware\esp32\

rename the folder
2.0.18-20240930.arduino3

to
2.0.18

2

[edit]
OK, got it now, thanks
[/edit]

BTW, I tried the blink example and it compiles without issues.

FQBN: arduino:esp32:nano_nora
Using board 'nano_nora' from platform in folder: C:\Users\bugge\AppData\Local\Arduino15\packages\arduino\hardware\esp32\2.0.18-20240930.arduino3
Using core 'esp32' from platform in folder: C:\Users\bugge\AppData\Local\Arduino15\packages\arduino\hardware\esp32\2.0.18-20240930.arduino3
...
...
Sketch uses 286157 bytes (9%) of program storage space. Maximum is 3145728 bytes.
Global variables use 30552 bytes (9%) of dynamic memory, leaving 297128 bytes for local variables. Maximum is 327680 bytes.
3

@ednieuw submitted a formal report about the long path problem here:

1 Like
4

Will that not break the auto update when the real 2.0.18 is released?

5

I just learned it will break the auto update.
This is a bug fix update followed in due time with a final update.

Renaming it to 2.0.18-20240930 also works and the IDE2 compiles without errors

And the IDE asks me to update to 2.0.18-20240930.arduino3.
So the auto update still works

6

I downloaded the zip and extracted it.

I post this comment here and not on github so the issue there is not polluted and others might learn from it.

IDE 2,x will not clear the cache on exit (or start). To clear the cache, you will need to delete (after closing the IDE)

  1. C:\Users\ednie\AppData\Local\Temp\arduino\sketches\
  2. C:\Users\ednie\AppData\Local\Temp\arduino\cores\

You actually only need to delete the specific ones (e.g. C:\Users\ednie\AppData\Local\Temp\arduino\sketches\4377DB218F2696AA45CED5D24E2DBC91) but I can't find the "matching" one for the core. It's safe to delete all the sub directories in sketches and cores (I do it regularly).

  1. Possibly (not sure) C:\Users\ednie\AppData\Local\Temp\52000059 if that still exists. It should be safe to do so; if in doubt make a backup.

This will however not help with your problem.

1 Like
7

That is a good point. It absolutely would. However, it is very unlikely there will ever be a real 2.0.18 release. The reason is that the esp32 platform developers are going to focus their limited resources on the modern 3.x version series rather than into working on a new version of the 2.x series.

1 Like
8

If you want something shorter that will meet the following criteria:

  • Doesn't break auto update to a hypothetical 2.0.18 release
  • Doesn't result in update offers for 2.0.18-20240930.arduino3

Then you can use something like 2.0.18-r.3.

Boards Manager compares versions using the SemVer precedence rules:

https://semver.org/#spec-item-11

  1. When major, minor, and patch are equal, a pre-release version has lower precedence than a normal version:
    Example: 1.0.0-alpha < 1.0.0.
  2. Precedence for two pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier from left to right until a difference is found as follows:
    1. Identifiers consisting of only digits are compared numerically.
    2. Identifiers with letters or hyphens are compared lexically in ASCII sort order.
    3. Numeric identifiers always have lower precedence than non-numeric identifiers.

In this case, the "-20240930.arduino3" and "-r.3" components in the version numbers make them "pre-releases" (2.0.18-20240930.arduino3 is actually a production release, not a pre-release, but the pre-release version number convention is used because the platform will always use the esp32 platform's version numbers for the major, minor, patch versioning). So 2.0.18-r.3 > 2.0.18-20240930.arduino3 (because "Numeric identifiers always have lower precedence than non-numeric identifiers"), but 2.0.18-r.3 < 2.0.18 (because "a pre-release version has lower precedence than a normal version").

The reason I included the .3 is because this allows you to increment that number if Arduino makes additional releases with 2.0.18 pre-release version numbers. I arbitrarily took the 3 from arduino3.

1 Like
9

FYI, an updated core was released today (2.0.18-arduino.5) and it includes multiple fixes on this topic (not only a shorter name! :face_with_hand_over_mouth:) that should close this issue for good.
If you are curious you can read some tech details here.

2 Likes
10

Great :+1:

11

Works here too :+1:

1 Like