Supported targets

ael check --target linux-x86_64
ael build --target linux-x86_64 -o build/support --release
ael build --target rp2040-pico -o build/sensors --release --memory-report

The targets

AEL 1.0.0 builds for these targets:

AEL 1.0.0 also builds for the ESP32 family of microcontrollers (ESP32-C3, ESP32-C6, ESP32-H2, ESP32-S3, ESP32 and ESP32-S2) and for coin-cell-class microcontroller boards:

• Targets that are not in these lists are not supported.
• A board named in the first table is covered by its exact name. Another board is not covered because its name is similar or it uses a related chip.
• Each board in the second table is a target of its own: its board support, which ael target install sets up, gives its target name and names its profile.

Profiles

Every target has a profile. A profile says what a target can offer a program, so you know before you build whether your program fits.

• One language reaches from servers down to microcontrollers, and a feature a target cannot support fails at compile time, not on the device.
• Runtimes come in sizes for each class of device, from servers down to coin-cell-class microcontrollers, and a program that does not fit its device's class is refused when you build it.
• A board's support names its profile, so the board decides the size of the runtime your program carries.
• Coin-cell-class and other small boards carry smaller runtimes than Nano's, with no heap and no operating system: agents take turns on a cooperative scheduler, with timers and mailboxes, each with a capacity fixed when you build, or, on the smallest boards, a program is one main loop and the interrupts it binds, with no scheduler.
• The smallest profile needs no heap and no operating system.
• An optional heap, storage, networking and TLS are available on small networked boards, such as the ESP32-C3.

The profiles are what your program can rely on, not brands of hardware. A single-board computer running Linux on ARM64 or x86-64, for example, is a Host target.

Subagents and network edges

• Subagents. An agent spawns subagents at run time: short-lived agents that each do one task, return a typed result to the agent that spawned them and end. Microcontroller boards create no agent at run time, so the check refuses spawn on them.
• Network edges. The same edge runs in one process, between processes or over the network, as your deployment places it, with no change to your source, and over the network it uses AEL's built-in gRPC-compatible transport with TLS. Microcontroller boards carry no network transport for edges, so on them an edge is never placed on the network.

Subagents and Communication between agents describe both.

Isolation and the sandbox

You mark an agent, node or subagent as isolated: it always runs in a sandbox in its own process, outside the shared communication layer, reachable only through the edges you declare and holding only the resources it declares itself. A function in another language runs on the same machine by default or in a sandbox, which needs the isolation facilities of Linux and runs only on the Linux target the documentation names for it, and a missing toolchain, a wrong version or a missing sandbox is refused before anything runs.

Isolated components and the sandbox for functions in other languages run on Linux on x86-64.

Isolation needs the isolation facilities of Linux and runs only on the Linux target the documentation names for it: on macOS, on Windows, on microcontroller boards, on other Linux targets and on any host without those facilities, an isolated component is refused, never run without isolation. A Linux host on x86-64 that lacks those facilities refuses both too. Isolated components and Functions in other languages describe them.

What a target check covers

When you check or build for a target, AEL checks that everything the program uses is available there: a heap on a Nano board, networking on a board that has none, a peripheral the board does not have, a spawn on a board, or a package limited to other targets. A mismatch fails the check with a diagnostic that points at your source, before anything is written to a device.

Isolation needs the isolation facilities of Linux and runs only on the Linux target the documentation names for it: on any host without those facilities, an isolated component is refused, never run without isolation.

You can limit a dependency in pack.ael to some targets with its targets field; see the Manifest reference.

AEL 1.0.0 is the full distribution; smaller distributions of the same version leave out components, such as support for other languages or for agents, and refuse a feature they leave out by naming it. Distributions describes them.

Where you develop

You develop on, and build for, the four operating-system targets above. The AEL 1.0.0 build for Linux, macOS or Windows comes with target management and a health check, and desktop and server programs written in AEL alone need nothing else installed.

Your application can hold private functions written in other languages, built and run with your own toolchains, pinned by version. A program that holds one needs that language's toolchain on the machine that builds it and on the machine that runs it.

Microcontroller boards are targets only: you build for them from one of those machines. A board target needs its own support, added with ael target install, and flashing a board needs its maker's flashing tools.

ael target install rp2040-pico
ael doctor

ael doctor reports the toolchain, the installed targets and anything that is missing, and ael target install describes setting up a target.

Related

• Desktop and server: building for the Host targets.
• Microcontroller boards: the boards of the Edge and Nano profiles and coin-cell-class and other small boards in detail.
• Containers: static Linux executables in minimal images.
• Distributions: the full distribution and the smaller ones.
• Isolated components: agents, nodes and subagents that run in a sandbox.
• Getting AEL 1.0.0: what the build for your platform sets up.