The Case for an EiffelStudio F_code Runtime SDK

Why a 4.7 MB redistributable runtime is the missing piece for Eiffel library deployment

The deployment problem

EiffelStudio is an exceptionally capable development environment. Its command-line compiler ec can build a complete Eiffel application without the IDE, and the finalized C output in the F_code folder is portable, auditable C that any C compiler can process. For developers building applications this workflow is well understood and well supported.

For library deployment the situation is different and more difficult. A project like xpact — a proposed Eiffel reimplementation of the widely-deployed libexpat XML parser with full Design by Contract annotations — needs to be consumable by developers who have no Eiffel knowledge and no EiffelStudio installation. A C developer linking against xpact should see a standard shared library and a C header. A Python developer should be able to install it via pip. A CI pipeline should be able to build it from source with nothing more than a C compiler and make.

Currently none of this is straightforward. Compiling the F_code output of an EiffelStudio finalization requires the Eiffel runtime headers and libraries, which are embedded inside the full EiffelStudio installation. A downstream builder who wants to compile xpact from source must install several hundred megabytes of EiffelStudio toolchain to access a few megabytes of runtime support files. This is a significant and unnecessary barrier to adoption.

The solution is already almost there

The good news is that EiffelStudio already decouples the compiler from the IDE — ec is a standalone command-line tool that works without EiffelStudio the application. The remaining step is to decouple the runtime from the compiler.

As the technical analysis below documents in detail, the complete set of files needed to compile F_code output on a target machine without ec or the IDE amounts to approximately 4.7 MB. This consists of:

• The finish_freezing build driver and supporting binaries — 2.1 MB
• The Eiffel runtime headers — 580 KB
• The finalized runtime libraries (static and shared, single- and multi-threaded) — 2.2 MB
• Two config templates — 16 KB

A developer with this 4.7 MB SDK, a C compiler, and make can compile any finalized Eiffel project from its F_code archive without any further Eiffel tooling. No ec. No EiffelStudio. No Eiffel knowledge required.

The precedent from other languages

This pattern — separating the compiler from the runtime for deployment purposes — is well established across systems languages. The D language ships druntime as a separately packageable library available in apt and rpm repositories independently of the DMD compiler. OCaml's libcamlrun is separately installable on all major Linux distributions. Go embeds its runtime entirely within the output binary, requiring nothing on the target machine at all.

In each case the motivation was the same: enabling library and application deployment in contexts where requiring a full compiler installation is impractical — CI pipelines, embedded build environments, package manager distribution, and third-party consumption of generated artifacts. xpact is precisely such a context for Eiffel.

What xpact needs

xpact is a proposed Eiffel streaming XML parser with a libexpat-compatible C API, full Design by Contract annotations, and a Python binding. Its deployment story requires:

• A C source distribution — an archive of the finalized F_code output plus the libexpat-compatible header, compilable by any downstream builder with a C compiler and the 4.7 MB runtime SDK.
• A pre-built shared library — libxpact.so / xpact.dll for direct linking by C and C++ applications.
• A Python package — a PyPI-installable wrapper that either bundles the pre-built shared library or builds from source using the runtime SDK as a build dependency.
• A .NET assembly — built via EiffelStudio's CIL backend, requiring no native runtime at all on .NET-capable systems.

The C source distribution and Python package paths both require the runtime SDK to be available as a standalone artifact. Without it, xpact cannot be distributed in source form to non-Eiffel developers — which is precisely the audience the project is designed to reach.

The request to Eiffel Software

The technical work required from ISE is bounded and well-defined: extract the 4.7 MB subset documented below from the EiffelStudio installation, package it as a standalone archive or installable package, and make it available under a licence that permits redistribution alongside projects built with EiffelStudio.

A formal EiffelStudio F_code Runtime SDK — versioned to match EiffelStudio releases, available as a standalone download and ideally as packages in major Linux distribution repositories — would remove the last practical obstacle to Eiffel-generated libraries being treated as first-class artifacts in standard software distribution workflows.

For projects like xpact whose entire purpose is to demonstrate that Eiffel can deliver production-quality, widely-deployable systems software, this SDK is not a convenience feature. It is a prerequisite.

xpact specifically needs only the base SDK

For a pure parsing library like xpact — no GUI, no network, no image processing dependencies — the minimal 4.7 MB runtime SDK is entirely sufficient. The C_library/ subset of EiffelStudio, which contains third-party C libraries such as cURL, zlib, libpng, and OpenSSL, is only needed for projects that explicitly link against those libraries. xpact is not one of them. Its dependency profile is as clean as a C library can be: Eiffel runtime plus the standard C library.

This is a deliberate architectural advantage. A parser library that requires no GUI toolkit, no network stack, and no image codec has no reason to carry those dependencies into its distribution. xpact can be distributed as a standard C source archive buildable anywhere with a C compiler and 4.7 MB of runtime support — a distribution story as clean as any C library.

A tiered SDK approach

Not all Eiffel projects have xpact's minimal dependency profile. EiffelVision2 applications require graphics support. Network-enabled libraries need cURL. The 4.7 MB base SDK serves pure Eiffel projects but would need augmentation for more complex cases.

This suggests a natural tiered packaging model that ISE could offer:

This model follows the precedent of Linux distribution packaging, where a library's runtime package and its development headers are separated, and optional dependency packages are installed only when needed. It keeps the common case small and the uncommon case possible.

Creating the SDK is straightforward

The technical specification in this document is precise enough that creating the SDK from an existing EiffelStudio installation requires nothing more than copying a defined set of files into a new directory and packaging the result. This is a task well suited to automation.

A Claude Code agent — Anthropic's agentic coding tool — is capable of generating a shell script that reads the file list documented below, extracts the relevant subset from a full EiffelStudio installation at a specified path, and produces a redistributable SDK archive. Such a script would also verify that the resulting SDK correctly builds a test F_code project before packaging, providing an automated correctness check. The script itself would serve as an executable specification of the SDK's contents — version-controllable, reproducible, and easily updated when new EiffelStudio versions are released.

The barrier to ISE creating and maintaining this SDK is therefore low. The specification exists. The automation is straightforward. The benefit to projects like xpact and to the broader Eiffel ecosystem is substantial.

The remainder of this document provides the precise technical specification of what the SDK must contain, derived from analysis of the EiffelStudio 25.12 installation on linux-x86-64.