Addition of a extensionpoint for tool providers and a tool provider manager.

[jantje]

As discussed in the CDT meeting of December 2023

CDT is dependent on the physical existence of tools on a locally reachable storage device.
I'm talking about tools like g++ gcc.
On a Linux/mac machine these are typically available from the OS installation packages but only to with the local OS as target.
On windows one needs to find a tool provider (like minGW) even for compiling for the local OS.
For a better user experience I think it is a good idea to create a extensionPoint for tool providers.
This extension point (Identified by a ID) should provide CDT with

a class that provides the following things:

• The FQN of the location of the tools (I'm assuming all the tools are available from the same location) (as known by CDT)
• A tool type key to identify the tools and tools options (For instance MVC has an extra tool ( a resource compiler) and mingw and gnu have different tool options) (As known by CDT)
• A tool prefix (as known by CDT)
• A tool suffix (as known by CDT)
• A tools key to identify the selected tools (there may be different tools and versions of these tools supported by a tool provider. CDT should store the ID of the tool provider and this key so the tool provider can provide the above 2 pieces of info)
• The number of available "tool chains" for a given tools key (or all tool chains when tools key is null)
• A user facing identifying name

The tool provider should also provide a gui interface that allows to select a tool/version.

This is because we know what CDT needs but we can not know what the tool provider needs.
The gui knows 2 modes. With and without a given tools key (we could also only have with and only allow tools key selection in the manager)

We will also need a tool provide manager

• The tool provider manager should provide a tool provider based on the tool provider ID.
• Provide a wizard page for the project creation
• Provide a project properties page

Some examples of tool providers

The most basic tool provider allows you to select a location on disk, the tool type and enter the prefix suffix). These are all concepts CDT already knows and handles. This tool provider should find a way to put this information in a "tools key")

A arduino based tool provider should allow you to select any of the arduino framework based installed tools by selecting the "tool provider" the "architecture" and "tool version".
As (nearly all) Arduino based toolchains are gcc based and come with a variant without tools prefix or suffix the tool provider could consider hard coding these.
The Arduino based tool provider should wrap these parameters in a tools key for configuration description persistence.

Final remarks

This will not solve the make availability.
This is what I currently have in mind. Comments/remarks/additions.... are very welcome

[jantje]

I found that this functionality is already implemented in CDT using IToolChainManager and IBuildTools.
Not via plugin.xml but via BundleContext getServiceReference
I still don't know how it exactly works though.