Cling: the interactive C++ interpreter that ROOT and Jupyter run on

A REPL on top of Clang, not beside it

Cling is an interactive C++ interpreter built on top of the Clang and LLVM compiler infrastructure, implementing the read-eval-print loop concept to leverage rapid application development. The implementation choice is stated precisely, a small extension to LLVM and Clang, which means the interpreter reuses their strengths, the praised concise and expressive compiler diagnostics named explicitly, rather than reimplementing a C++ parser. The practical consequence is that the errors, warnings and template diagnostics a user sees in the REPL are the same ones a modern C++ compiler produces, the property that makes an interactive C++ experience credible, since a REPL with worse diagnostics than the compiler is a toy. The project lives under CERN's root-project organization, its origin being the interpreter inside ROOT 6. The repository layout reflects the extension architecture, include and lib directories carrying the interpreter code, patches holding the modifications against upstream LLVM, and a demo directory whose ExpressiveDiagnostics example showcases exactly the error message quality the project advertises as inherited.

Two build routes, one pinned fork

The build instructions split in two, and the second is labeled recommended. Standalone means building LLVM first, cloning the root-project llvm-project fork, checking out the cling-latest branch, configuring with LLVM_ENABLE_PROJECTS set to clang and LLVM_TARGETS_TO_BUILD set to host and NVPTX in Release mode, then building. The combined route clones both repositories and configures once with LLVM_EXTERNAL_PROJECTS set to cling and LLVM_EXTERNAL_CLING_SOURCE_DIR pointing at the clone, building with the target clang cling. The NVPTX target in the default configure line is a quiet signal of the GPU-aware use cases, and the warning attached to both paths matters, ensure you are outside the llvm-project and llvm-build directories before proceeding, as LLVM, Clang and Cling do not allow building inside the source directory. The pinned cling-latest branch is the mechanism that keeps the fork relationship manageable, LLVM moves faster than Cling releases, and pinning the interpreter to a known-good LLVM state means a build that worked for v1.3 keeps working, at the cost of building LLVM from source rather than using a distribution package.

Hello world, in one process invocation

The usage examples show the two modes' difference in include paths. Built standalone, Cling needs the header directory specified:

./bin/cling -I"../cling/include" '#include <stdio.h>' 'printf("Hello World!\n");'

built as part of LLVM, the same program runs without the flag:

./bin/cling '#include <stdio.h>' 'printf("Hello World!\n");'

Getting started interactively is ./bin/cling --help for options or ./bin/cling alone, dropping into the cling square bracket prompt where .help lists the interpreter's meta commands. The one-liner form, statements passed as quoted arguments, is the scripting entry, and the prompt is the exploration entry, the two ways an interpreter earns its place over a compiler.

Debugging JITted code, with costs stated

Interpreted code is JIT-compiled, and Cling provides support for debugging and profiling it, with both capabilities documented as having a runtime cost and therefore disabled by default. Setting CLING_DEBUG to 1 enables debug symbol emission on interpreted code, allowing the use of a standard debugger, aided by switching off optimizations and adding frame pointers for better stack traces. Setting CLING_PROFILE to 1 enables perf profiling, and the mechanics split by JIT linker, with jitlink enabled through CLING_JITLINK, noted as soon the default, profiling requires a perf inject step, running perf record with the minus k 1 option, then perf inject with -j and finally perf report on the jitted data file, while the legacy path uses perf map files with no inject step. The three environment variables turn an interpreter session into a profiled, debuggable program, which is what makes it viable for performance-sensitive exploration. The optimization switch inside debug mode is worth internalizing, debugging JITted code at full optimization produces stacks that do not correspond to source lines, so the interpreter trades speed for traceability exactly when a human is watching, and returns to full speed when the variables are unset.

A Jupyter kernel for C++

Cling comes with a Jupyter kernel, and the enablement is a build target, after building cling run the build with the target libclingJupyter. Installation then follows the README in the tools/Jupyter directory, installing Jupyter and the kernel, with one operational requirement stated plainly, make sure cling is in your PATH when you start jupyter. The combination is significant beyond convenience, it put genuine C++ into the notebook workflow that had belonged to Python and R, and the ROOT ecosystem's analysts drove the need, exploring data with C++ interactively in the same interface their Python colleagues used. The libclingJupyter target being part of the main build rather than a separate repository keeps the kernel in lockstep with the interpreter. For teams mixing languages, the kernel means a notebook can hold a C++ cell beside Python ones, sharing the same Jupyter machinery of saved state, inline rendering and export, which is often the deciding factor for data analysis groups that cannot rewrite their analysis code.

Citations, releases, and the ROOT pedigree

The peer-reviewed citation anchors the project's history, the paper Cling, The New Interactive Interpreter for ROOT 6 by Vassilev, Canal, Naumann, Moneta and Russo, presented at the 19th International Conference on Computing in High Energy and Nuclear Physics in New York in May 2012 and published in the Journal of Physics Conference Series. Releases are versioned independently of ROOT, v1.1 in August 2024, v1.2 in December 2024 and v1.3 on 2026-02-11, and the release process is documented step by step, updating the release notes, removing the dev suffix from the VERSION file, adding a website news entry, committing, tagging with an annotated git tag, and tagging cling-patches of clang.git as cling-v with the version, the paired tags encoding the fork relationship. Nightly binary snapshots are stated as currently unavailable, so source building is the path. The paired tagging, one tag on the Cling repository and one on the clang fork for the same release, is what makes the pinned build reproducible years later, since the instructions reference the cling-latest branch that those clang tags define.

Copyright assignment, and old links kept honestly

The contribution section carries a policy few projects state so directly, every contribution is considered a donation and its copyright and related rights become exclusive ownership of the person who merged the code or the main developers of the Cling Project, with the rationale given, the transfer is necessary to effectively defend the project in case of litigation. Contributors are credited in the contributors page, release notes and the CREDITS file shipped with every distribution, so attribution survives the assignment. The resources section links talks, blog posts and conference videos from 2012 with a candid warning attached, some of the resources are rather old and most of the stated limitations are outdated, an honesty about documentation decay that serves newcomers more than polished silence would. For corporate contributors, the assignment model also simplifies the receiving side, the project holds clean title to its codebase, avoiding the license-compatibility audits that distributed-copyright projects face when ownership questions arise.

Editorial conclusion

Use Cling when C++ needs an interactive loop, teaching, algorithm prototyping, or driving ROOT-style data analysis without edit-compile cycles, and when the language semantics must be genuine C++ rather than a lookalike scripting dialect. Choose a compiled workflow when performance or tooling maturity dominates. Before building, accept the two-stage process, a cling-latest checkout of the root-project LLVM fork first or the combined LLVM_EXTERNAL_PROJECTS build that the project recommends, keep every build directory outside the source trees since LLVM, Clang and Cling refuse in-source builds, and note the copyright assignment policy on contributions before submitting code, since merged work becomes the project's.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. root-project/cling on GitHub