Use of defines in reproducible builds

[RobTillaart]

Often builds have command line defines

As these defines are part of the build they must be includable in the profile. e.g.

profiles:
  nanorp:
    fqbn: arduino:mbed_nano:nanorp2040connect
    platforms:
      - platform: arduino:mbed_nano (2.1.0)
    libraries:
      - ArduinoIoTCloud (1.0.2)
    defines:
      - SIZE: 128
  
  other:
    fqbn: ...
    platforms:
      - platform: ....
    libraries:
      - ....
    defines:
      - SIZE: 64

If the user defines the define on the command line, it overrules the value in the profile

arduino-cli compile [sketch] --DSIZE=256--profile myProject

[cmaglie]

Yep, this opens another can of worm :-) but we are definitely going to implement this one in a later revision of the profiles.

The main issue here is that there isn't a common pattern in the platforms.txt to add the extra -D properties, so we should probably create a new platofrm.txt "variable" for this specific purpose and wait for various 3rd party cores maintainers to adopt it (BTW they revealed to be pretty quick, so this may get through in a reasonable time).

[DeeEmm]

The main issue here is that there isn't a common pattern in the platforms.txt to add the extra -D properties,

Is this not already defined within the CLI as custom board options as a parameter of the FQBN?

All of these parameters follow typical key->value format so it should be trivial to allow these within the platforms.txt

i.e.

profiles:
  ESPduino:
    fqbn: esp32:esp32:esp32
        FlashMode qio
        UploadSpeed 115200
        PartitionScheme no_ota

With strict YAML conventions, indenting makes these parameters a subset of the fqbn, so we do not need to define additional variables to store them in unless we need to access these parameters publicly.

so we should probably create a new platofrm.txt "variable" for this specific purpose and wait for various 3rd party cores maintainers to adopt it (BTW they revealed to be pretty quick, so this may get through in a reasonable time).

using the above format is transparent to third party maintainers as it follows the current convention of adding parameter values to the fqbn. It also degrades nicely to the current system as using no platform.txt file just falls back to the current way of doing things.

In addition to this, it should be possible to do the following in addition to the above,

profiles:
  ESPduino:
    fqbn: esp32:esp32:esp32:FlashMode=qio:UploadSpeed=115200:PartitionScheme=no_ota

Which is essentially the same as we currently have. It also make an easy interim solution and should be dead simple to implement