Toolchains — choosing the Python, compilers and simulators ICore Blocks runs#

Some of what ICore Blocks does is done by programs installed on your computer rather than by the application itself. Checking exported code runs that code with its own compiler or simulator. A C Code block is compiled with your C compiler. The Git panel runs git. The Toolchains page is where you see which program is used for each of these, and choose a different one.

Open it from the left rail: Configuration ▸ Toolchains, or View ▸ Tool Panels ▸ Toolchains for a window of its own.

What is on the page#

One row per program, grouped the way you would look for them:

Each program is a bar showing a coloured dot, its name, and the version and path of the program that will run. The search box at the top narrows the list by name, version or path. The dot's colours:

• green — found, and it has everything it needs;
• amber — found and it runs, but something one feature needs is missing. The usual one is a Python without numpy: the coding-agent client works, checking exported Python code does not;
• red — nothing usable: not installed, a program that does not start, or a file you chose that is no longer there;
• grey — still being checked. The page never makes you wait: rows fill in as each program answers.

Click a program's bar to open it: which installation to use, the whole path, how it was found (your choice, an environment variable such as JAVA_HOME, your shell's PATH, or a standard install folder), which features use it, and what it needs. When something is missing, Fix shows the one line that fixes it, with a Copy button — for Python without numpy, that is the pip install command for that Python. When the program cannot be used at all, the reason is spelled out in red underneath. Test checks the program again, Browse… chooses a file, and Copy Path copies the path.

The bar along the bottom of the page counts how many programs are ready, with a progress bar while they are being checked. Rescan looks for everything again — use it after installing a program or changing your PATH.

Choosing a program#

Open a program and use its Installation drop-down. It lists:

• Auto-detect — the default. ICore Blocks looks everywhere it knows to look and uses the best installation it finds: one that has everything it needs beats one that does not.
• Every installation it found, with its version and path — a machine with Python from Homebrew, from pyenv and from the system shows all three. Picking one pins it.
• Choose a file… — pin any program, for instance one in a folder ICore Blocks does not know about.

A pinned program is used exactly as chosen. If it lacks something, the row says so in amber; it is never swapped for another one behind your back. If the file is later deleted or moved, the row turns red and still names the file you chose — pick Auto-detect or another file to move on.

Your choices belong to this computer and are kept with the application's settings, not in your projects, so a project opened on another machine uses that machine's programs.

Why a program your terminal finds may be "not found" here#

An application opened from the Dock or Finder does not see the PATH your terminal has — which is exactly where Homebrew, pyenv and rustup install their programs. ICore Blocks asks your login shell for its PATH when it starts, and also looks in the standard install folders (/opt/homebrew/bin, ~/.cargo/bin, /Library/Java/JavaVirtualMachines, /Applications/MATLAB_*.app, and their Windows and Linux counterparts). If a program is still not found — it lives somewhere unusual, or your PATH is set somewhere a login shell does not read — choose it with Choose a file….

ICore Blocks installs none of these programs itself. matiec is the one package managers rarely carry: build it from its source (github.com/beremiz/matiec), then choose its iec2c. Keep the lib folder that comes with it next to iec2c, because it is needed there. You only need matiec to check exported PLC code.

On Windows#

Several installers on Windows put nothing on PATH, so ICore Blocks also looks where each one installs:

• C and C++ — the Visual Studio compiler (cl.exe, from Visual Studio or the Build Tools, found through the Visual Studio Installer) and MSYS2's gcc / g++. You do not need a Developer Command Prompt: the environment the Visual Studio compiler needs is set up for it. On a Windows-on-Arm PC, an MSYS2 compiler that builds x64 programs is shown in amber — it can check exported code, but the C Code block cannot load what it builds — and the Visual Studio compiler is preferred.
• Python — every installation the py launcher knows about, plus the usual install folders. The python.exe Windows provides as a shortcut to the Microsoft Store is shown as rejected until you actually install Python from the Store.
• Rust in %USERPROFILE%\.cargo\bin, Java from JAVA_HOME and the usual JDK folders, MATLAB under Program Files\MATLAB, GHDL and Icarus Verilog in MSYS2, and Git for Windows.

From the command window#

The same answers, and the same choices, are available as the toolchain command — useful in scripts and when running ICore Blocks without a window:

The names are python, cc, cxx, rust, jdk, matlab, ghdl, iverilog, matiec and git. toolchain set refuses a path that is not a file and changes nothing; it pins a file that turns out not to be usable, but reports the command as failed so a script stops there.

The Python inside the application#

Python Code blocks and Python-model blocks run on a Python that ships inside ICore Blocks, with numpy. It is listed at the bottom of the page under Bundled with the app, for reference, and is not chosen here: it is built into the application, and cannot be swapped for another installation. The Python row above it is the separate, installed Python that checks exported code.