Building ATS2 from Source in 2026

The journey of building ATS2 from source in 2026 reveals much about the challenges of maintaining niche but powerful programming language ecosystems. This article provides a meticulous documentation of the author's experience navigating the complexities of constructing both ATS1 and ATS2 from their GitHub repositories, offering valuable insights for developers interested in this formally-oriented programming language.

ATS represents a distinctive approach to program verification, integrating proof construction directly into the type system rather than layering it as annotations. This fundamental design choice distinguishes it from alternatives like Verus for Rust, creating a programming paradigm where proofs become first-class values that can be constructed and passed around within the language itself. The compilation process transforms ATS code into standard C, with proofs erased during compilation, resulting in efficient executables without runtime overhead—a compelling proposition for developers seeking both safety and performance.

The central challenge encountered in this endeavor stems from what the author aptly identifies as "bitrot" in the project infrastructure. The last official ATS2 release, version 0.4.2, dates back to 2020, while development continues actively on GitHub. This discrepancy creates a significant gap between available documentation and current build requirements, forcing developers to navigate through outdated guides and broken build artifacts. The absence of recent release tarballs means that building from source becomes the only viable path for newcomers, introducing a substantial barrier to entry for a language that already presents a steep learning curve.

The technical details presented in the article illuminate the intricate dependency chain between ATS1 and ATS2. The ATS2 compiler is written in ATS1, necessitating a successful build of the first system before attempting the second. This dependency reveals a fragile build infrastructure where the ATS1 repository contains broken autotools symlinks pointing to non-existent automake installations, missing directories, and compatibility issues with newer macOS versions. These issues, while seemingly minor, create significant friction for developers attempting to get started with the language.

The platform-specific nuances further complicate the build process. On Linux systems with Debian/Ubuntu, the prerequisites remain straightforward, requiring only build-essential, automake, bison, and libgmp-dev. However, macOS with Homebrew introduces additional complexity, requiring careful path management for bison and GMP, along with environment variable configurations to handle implicit function declaration warnings that Apple Clang treats as errors while GCC merely warns. These platform differences highlight the challenges of maintaining cross-platform compatibility in niche programming language ecosystems.

The article meticulously documents workarounds for each encountered obstacle. For the broken autotools symlinks in ATS1, the author demonstrates how to replace them with actual scripts from the system's automake installation. The missing bootstrap1 directory requires manual creation, suggesting either a discontinued build step or an oversight in the repository maintenance. The macOS-specific issues necessitate creative solutions, including a wrapper script for atscc to properly handle compiler flags that the tool cannot parse directly.

The verification of each build step provides a blueprint for developers attempting to reproduce the process. The author confirms successful ATS1 compilation by checking the atsopt version and explains the apparent discrepancy between the reported version (0.2.13) and the required ATSHOMERELOC value (ATS-0.2.12), clarifying that these serve different purposes in the build system. This level of detail demonstrates a deep understanding of the build infrastructure and provides readers with the diagnostic tools needed to troubleshoot their own build failures.

The creation of a release tarball represents an interesting alternative approach to building from source. By generating pre-compiled CBOOT files, the distribution becomes self-contained, requiring only a C compiler for installation. This method bypasses the need to build ATS1 entirely, offering a more accessible on-ramp for new developers. The documented steps for generating such a tarball reveal the sophisticated build infrastructure that exists within the project, suggesting that while the main repositories may suffer from bitrot, the release generation process remains functional.

The implications of this technical exercise extend beyond the immediate goal of building ATS. It illustrates the broader challenges faced by formally verified programming languages in achieving widespread adoption. The friction introduced by build system issues, documentation gaps, and platform-specific quirks creates unnecessary barriers that can deter potential adopters. For a language already positioned as a specialized tool requiring significant investment to learn, these additional obstacles represent a substantial impediment to growth.

From a counter-perspective, one might argue that the complexity documented here reflects the inherent difficulty of creating and maintaining sophisticated type systems with formal verification capabilities. The intricate build process and platform-specific issues could be seen as natural consequences of pushing the boundaries of what is possible in programming language design. However, this perspective overlooks the fact that many equally complex languages have managed to provide smoother onboarding experiences, suggesting that the challenges faced here are not insurmountable but rather symptoms of maintenance priorities.

The article concludes with a pragmatic assessment of the current state of ATS development, acknowledging that while building from source requires working through several pain points, it remains achievable on both Linux and macOS. This balanced perspective offers hope for developers interested in exploring ATS while setting realistic expectations about the effort required. The inclusion of further reading resources demonstrates a commitment to helping readers continue their exploration beyond the immediate build process.

For programming language enthusiasts and researchers interested in formal methods, this article serves as both a practical guide and a case study in the challenges of maintaining niche but technologically significant software. The detailed documentation of build fixes and workarounds contributes valuable knowledge to the community, potentially saving others the time and frustration of rediscovering these solutions. As the landscape of formally verified programming languages continues to evolve, such documentation plays an increasingly important role in preserving access to foundational technologies that may otherwise fade into obscurity.

Relevant Resources:

• ATS-Anairiats on GitHub (ATS1)
• ATS-Postiats on GitHub (ATS2)
• ATS Official Website
• Introduction to Programming in ATS
• Verus for verification on Rust

{{IMAGE:1}}