Seperate out the chips.gcc_toolchain in the context of idf-install.py Vs linking

[gopakumarce]

trafficstars

See thread https://github.com/esp-rs/esp-idf-sys/issues/271 and https://github.com/espressif/crosstool-NG/issues/50

The toolchain name that is supplied to idf-install.py Vs what is actually used when compiling/linking can be slightly different - the installation can be given one toolchain name and underneath installs multiple things, and at compile/link time one of those installed tools is selected based on the specific idf target

[Vollbrecht]

in the light of https://github.com/esp-rs/esp-idf-sys/issues/235 and as a mitigation possible usage of clang instead of gcc. Did you find evidence that currently idf-install.py offers functionalists to run with clang?

[gopakumarce]

@ivmarkov any thoughts on this :-?

[ivmarkov]

@ivmarkov any thoughts on this :-?

I don't understand the problem still. Can you elaborate what is the problem, and what you would like to see changed?

[gopakumarce]

@ivmarkov any thoughts on this :-?

I don't understand the problem still. Can you elaborate what is the problem, and what you would like to see changed?

@ivmarkov sorry for the confusion - the context for this is https://github.com/esp-rs/esp-idf-sys/issues/271 - its a minor thing, if I want to get the gcc that I can use to then compile a C file and produce a .o (during bindgen), I cannot use chips.gcc_toolchain() because it returns xtena-esp-elf .. xtensa-esp-elf can be supplied as the parameter to idf-install.py which is just fine, it will install the right toolchains. But when compiling, we have to give xtensa-esp32-elf or xtensa-esp32ss-elf etc.. (pls see the thread with the xtensa compiler person https://github.com/espressif/crosstool-NG/issues/50 )

So all I am doing here is to basically say that the toolchain name supplied as an idf-install.py parameter is different from the exact toolchain name used for compilation, and keeping seperate APIs for that