path to upload tools in "platform.txt"

[gicking]

On my PC (Ubuntu with Arduino 1.8.6) uploading via stm8flash or stm8gal fails with (in German): java.io.IOException: Cannot run program "{runtime.tools.STM8Tools.path}/linux/stm8gal": error=2, Datei oder Verzeichnis nicht gefunden

But if I apply the below change to platform.txt it works

#tools.stm8flash.path={runtime.tools.STM8Tools.path}/linux
tools.stm8flash.path={runtime.hardware.path}/tools/linux
...
#tools.stm8gal.path={runtime.tools.STM8Tools.path}/linux
tools.stm8gal.path={runtime.hardware.path}/tools/linux

Actually I had already found this earlier, but you mentioned that hardware.path has been obsolete since Arduino 1.6 (see here). I assume that this works on your system, so do you have any idea why mine behaves different...?

Thanks a lot in advance!

[tenbaht]

At the very beginning of your platform.txt you should find these lines:

# General folder structure variables
# ----------------------------------
# For Board Manager installs these variables are already predefined and will
# not be overwritten. This assignment is done only for manual installs.
#
# Apparently, this trick only works for compiler settings, not for the
# upload process. The upload process is not handled by arduino-build, but
# the IDE itself and behaves slightly differently.
# Problem is in Arduino/arduino-core/src/processing/app/BaseNoGui.java
# function createToolPreferences():
#       PreferencesData.removeAllKeysWithPrefix(prefix);
# FIXME: find a solution to allow for uploads with manual installations.
runtime.tools.sdcc.path={runtime.hardware.path}/tools/sdcc
runtime.tools.STM8Tools.path={runtime.hardware.path}/tools

At least on my system this fixes this issue. The variable {runtime.tools.sdcc.path} is defined, but if it was already predefined (from a board manager install) the existing definition is not overwritten. I analysed the source code for ardunio-build for Arduino-1.8.5 to find this workaround. Checking here with a fresh 1.8.7 install still works.

This expects the sdcc dir tree in hardware/sduino/tools/sduino (as a copy or a symlink):

cd ~/Arduino/hardware/sduino/tools
ln -s /opt/sdcc sdcc

Maybe you have an outdated board manager install still active? Could you please check the board manager if the sduino package is still listed as installed? If yes, remove it. This will only effect the board manager installation in ~/.arduino15/packages/sduino/. It won't touch anything in ~/Arduino/hardware/sduino or ~/sketchbook/hardware/sduino

[gicking]

darn, no luck here: 1) platform.txt is from repo, i.e. same as shown above 2) I have linked linux and sdcc as described. Also with tools.stm8flash.path={runtime.hardware.path}/tools/linux it works 3) in board manager sduino shows up as not installed

I guess I simply have to use my old-style platform.txt...

[tenbaht]

This was fixed by commits eb7868d3 and e32c670f (would have been better to integrate them into one commit).

From the commit message for e32c670f:

The Arduino IDE handles the tool path differently for manual installs and for packages that have been added by using the board manager.

For the compile step it is possible to overcome that problem by redefining two automatic variables. These redefinitions only work for manual installs. For board manager installs they are ignored and the variable keep their automatic values. This is an ugly trick, but it works:

runtime.tools.sdcc.path={runtime.hardware.path}/tools/sdcc
runtime.tools.STM8Tools.path={runtime.hardware.path}/tools

Apparently, this trick only works for compiler settings, not for the upload process. The upload process is not handled by arduino-build, but the IDE itself and behaves slightly differently. Problem is in Arduino/arduino-core/src/processing/app/BaseNoGui.java function createToolPreferences():

PreferencesData.removeAllKeysWithPrefix(prefix);

This manual/automatic install shisma is now overcome by patching the platform.txt in the process of generating the board manager packages.

Before packaging, the string "{runtime.hardware.path}/tools" is replaced by "runtime.tools.STM8Tools.path" in all tools.stm8.* lines.

This is another ugly workaround, but again, it works. (hopefully)