Give the runtime.ide.version property a more meaningful value

[per1234]

trafficstars

Feature Request

Current behavior

The ARDUINO macro is defined with the value of the runtime.ide.version property. When using the Arduino IDE, this value matches the current IDE version. When using other Arduino development software, it has a meaningless value (currently 10607):

https://github.com/arduino/arduino-cli/blob/625aaac8bee07f5ea2e859e59d718ed2d11bc5f1/internal/arduino/cores/packagemanager/package_manager.go#L417

This causes problems for code that uses the value of the ARDUINO macro to determine compatibility with version-specific behavior of the Arduino development software (e.g., function prototype generation).

Expected behavior

My suggestion is to set the runtime.ide.version property to the version of the Arduino IDE the Arduino CLI release will be used with. I think that, given the historical meaning of this property's value, this will provide the closest match to the behavior the user expects.

Arduino CLI version

Original report

0.10.0-rc1 Commit: 8220b32

Last verified with

625aaac8bee07f5ea2e859e59d718ed2d11bc5f1

Operating system

• Windows
• Linux

Operating system version

• Ubuntu 22.04
• Windows 11

Additional context

If the policy for setting the value of the runtime.ide.version property is changed, the relevant section of the Arduino Platform Specification should be updated accordingly: https://arduino.github.io/arduino-cli/dev/platform-specification/#global-predefined-properties

Additional requests

• https://github.com/arduino/arduino-cli/issues/725#issuecomment-1718052299
• https://github.com/arduino/arduino-cli/issues/725#issuecomment-1986986168

Related

• https://github.com/SpenceKonde/ATTinyCore/issues/405

[matthijskooijman]

I guess that part of this should be solved by specifying a core version (I guess that could be added already?) and an Arduino API version implemented by the core (which I think needs ArduinoCore-API to become more widespread), which allows code to check those versions rather than the IDE version.

My suggestion is to set the runtime.ide.version property to the version of the Arduino IDE the Arduino CLI release will be used with. I think that, given the historical meaning of this property's value, this will provide the closest match to the behavior the user expects.

Yup, that seems like a good way to handle this.

[cmaglie]

My suggestion is to set the runtime.ide.version property to the version of the Arduino IDE the Arduino CLI release will be used with. I think that, given the historical meaning of this property's value, this will provide the closest match to the behavior the user expects.

This can be easily done and makes sense, btw there is still the question of which value should be used when the CLI runs standalone. Probably we should keep 10607 as the default?

@matthijskooijman

I guess that part of this should be solved by specifying a core version (I guess that could be added already?) and an Arduino API version implemented by the core (which I think needs ArduinoCore-API to become more widespread), which allows code to check those versions rather than the IDE version.

This has been already done in the ArduinoCore-API https://github.com/arduino/ArduinoCore-API/blob/e26862e453c1234e1c23506d1839bfa68999d911/api/ArduinoAPI.h#L24 I think that this is already handled by the C++ compiler, so it doesn't need any special support in the CLI.

[matthijskooijman]

This has been already done in the ArduinoCore-API

This is only half of my suggestion (API version, not core version), but indeed, the core version also does not need support in arduino-cli and can be handled in .h files only.

Thinking more about the runtime.ide.version, I wonder if this should be used at all in the future, given that like you say arduino-cli can be run without an IDE as well. Adding a runtime.arduino-cli.version might make sense, but in the future tooling might further change and expecting cores to support all of these properties is not really feasible (but auto-generating -D options instead of setting properties probably isn't great either), so maybe these properties are not really needed at all then? So maybe just freeze runtime.ide.version? In the end, code should probably care about core and API versions more than IDE/tooling versions, of course..

[cmaglie]

so maybe these properties are not really needed at all then? So maybe just freeze runtime.ide.version?

That's exactly what I'd like to do, previously {runtime.ide.version} was linked to the AVR core version, AFAIU the -DARDUINO={runtime.ide.version} define worked as a sort of alias to the AVR core version. This allowed, for example, a smooth transition when some breaking changes were introduced in the ArduinoCore API (notably the Wire.write() method incompatibility).

When the AVR platform has been decoupled from the IDE (starting from IDE 1.8.x and the package manager), the usefulness of the ARDUINO constant began to fade away, I'm not aware of any other usage than that.

We could not remove it completely because there are a lot of libraries using the pattern:

#if ARDUINO > 100
   ....
#else
   ....
#endif

that requires the ARUDINO constant to be defined and > 100.

So, unless I'm missing something else, I'd just freeze {runtime.ide.version} to the value 10819, which is the latest 1.8.x IDE release and deprecate it.

[derniwi]

Hi,

I also have this issue, currently working on a ESP32 project. To get around with my own libraries, what is the recommended way to determine the current used IDE version?

Regards Nils

[Eheran1]

I also have this issue with an ESP32 project. What is the recommended way to determine the current used IDE version?

[derniwi]

Hi,

I did not receive an answer yet. But currently there are so many different CPUs supported by Arduino IDE, including systems manually added like ESP32. So I'm not sure if it still make sense to check for the Arduino IDE version.

There are several other values you might check:

// Get the ESP Arduino version in Format a.b.c
// ..\Arduino15\packages\esp32\hardware\esp32\2.0.14\cores\esp32\esp_arduino_version.h
const char *getArduinoPlatformVersion() {
  static char version[8];  // x.xx.xx\0
#ifdef ESP_ARDUINO_VERSION_MAJOR
  sprintf(version, "%d.%d.%d", ESP_ARDUINO_VERSION_MAJOR, ESP_ARDUINO_VERSION_MINOR, ESP_ARDUINO_VERSION_PATCH);
#endif
  return version;
}

Serial.printf("Used IDF version for compilation: %s\n", esp_get_idf_version());
Serial.printf("Used ESP arduino platform for compilation: %s\n", AduinoPlatformVersion());
Serial.printf("Used IDE version for compilation: %u\n", ARDUINO);
Serial.printf("GNU C++ version: %s\n", __VERSION__);
Serial.printf("C++ standard: %ld\n", __cplusplus);

Maybe this is something which might help you.

Regards, Nils