Hylo Compiler Repository: Building the hc Tool from Source

Why the Hylo Compiler Repository Exists

Hylo addresses high-level systems programming through two stated language design ideas: mutable value semantics and generic programming. Mutable value semantics allow values to be modified while the language maintains a particular model of value behavior, while generic programming provides a way to write abstractions that work across types. Those ideas are the central reason this repository is a compiler implementation rather than a general Swift utility library.

The target audience is narrow. Developers working on the Hylo language, its compiler, its standard library, or its implementation tests need the `hc` executable and the surrounding Swift package. The repository is not presented as an installer for everyday Hylo applications. Its build process depends on a specific LLVM release and on repository submodules, so it is primarily relevant to contributors and compiler researchers.

There is also an important project-boundary issue. The README calls this the former implementation of Hylo and says that most efforts now go toward the new compiler in `hylo-lang/hylo-new`. New contributors are explicitly encouraged to target that repository. This means the code here can still be useful for understanding or building the former implementation, but its position in the project roadmap differs from that of the newer compiler repository.

The hc Build Pipeline and Repository Structure

The compiler is written in Swift and is distributed as a Swift package. The package uses LLVM 20 as packaged by Hylo, and the build also requires access to the repository's submodules. The README states that the LLVM package includes a `.pc` file for Swift Package Manager and enables assertions to help expose mistakes during development.

The repository layout reflects several parts of the toolchain. `Sources/` contains compiler source code, `StandardLibrary/` contains the language-side standard library, `Tests/` contains the test suite, `Examples/` contains Hylo programs, and `Tools/` contains development utilities. `CMakeLists.txt`, `Package.swift`, and supporting files provide two build paths. The top-level `x.ir` and implementation strategy documents indicate that the repository includes compiler-facing intermediate artifacts and design documentation, although the README does not explain their internal runtime flow in detail.

The documented output is an executable named `hc`, created in `.build/release` by the Swift Package Manager workflow. The compiler can also be built through CMake and Ninja, and the README provides an Xcode-oriented CMake route for macOS users. The actual source transformation pipeline is not documented in the README, so details such as parser stages, IR names, optimization passes, or linking behavior should not be inferred from repository entry names alone.

Building hc with Swift Package Manager

The shortest documented build path uses Swift Package Manager after the repository and its submodules have been prepared. The README requires Swift 6.2 or higher and LLVM 20. If Xcode is not being used, the LLVM installation's `pkgconfig` directory must be added to `PKG_CONFIG_PATH`. The README gives these commands:

git submodule update --init
swift build -c release
swift test -c release

The first command populates the submodules after cloning. The build command creates the compiler executable at `.build/release/hc`. The test command runs the package tests in release configuration, although the README later gives a parallel form for testing the compiler:

swift test -c release --parallel

This route requires more setup than a normal standalone compiler download. `pkg-config` must be installed, the LLVM package must be available, and `PKG_CONFIG_PATH` must point to the correct package metadata unless Xcode is handling the lookup. The README also notes that development containers have LLVM and its `.pc` file preinstalled.

CMake and Ninja Configuration for the Compiler

CMake is the more explicit route because it exposes the LLVM directory, build type, testing option, generator, and source tree separately. The README instructs contributors to replace `<LLVM>` with the root directory of their LLVM installation and to use `Debug` or `Release` as the build type.

cmake \
  -D LLVM_DIR=<LLVM>/lib/cmake/llvm \
  -D CMAKE_BUILD_TYPE=Release \
  -D BUILD_TESTING=1 \
  -G Ninja -S . -B .build
cmake --build .build
ctest --parallel --test-dir .build

The configure step expects LLVM 20 at the supplied `LLVM_DIR`. The build step compiles the project into the selected CMake build directory. The test step is available because `BUILD_TESTING=1` was included during configuration. The README gives no separate output path for a CMake-built `hc`, so users should inspect the generated build directory rather than assume that it matches the Swift Package Manager location.

On macOS, the documentation warns that CMake may need an explicit Swift compiler or SDK path when Xcode selects an unintended toolchain. On Windows, symbolic links require support, and `VSINSTALLDIR` must point to the Visual Studio installation directory without a trailing slash so LLVM's CMake files can locate the DIA SDK. Those constraints make the build less portable than a normal language package.

Devcontainers, Examples, and First Hylo Use

For developers on systems other than Linux, the repository includes a Devcontainer specification. The README says Hylo supports Linux natively and that its Linux CI uses this specification. VSCode is the IDE used by the team, but the specification is intended to work with other IDEs that support Devcontainers. The repository files are mounted into the container, so edits made on the host are visible inside it. Changes under `.devcontainer` require a container rebuild.

After opening the project, VSCode prompts for recommended extensions from `.vscode/extensions.json`. If the prompt does not appear, the README says to install the listed extensions manually. Rebuilding through `Dev Containers: Rebuild and Reopen in Container` prepares the Linux environment. A terminal inside that environment can then use the documented CMake or Swift Package Manager workflows. The README suggests checking the shell identity with `whoami`, expecting `vscode`.

The repository contains examples named `hello.hylo`, `fortytwo.hylo`, `factorial.hylo`, and `concurrent_greeting.hylo`. The README does not give a command that invokes `hc` on one of these files, so it would be inaccurate to invent a compiler command or claim how output appears. The documented first executable check is building the package and locating `.build/release/hc`.

Maintenance Signals and Change Costs

The repository is not archived. Its last push was on 2026-10-14. The README also says the project is under active development and warns that things may break and APIs may change. Those statements describe the repository's own status, but the same README says most efforts now go toward `hylo-new`, which is a significant cost for anyone planning long-term contribution work.

The recent release listed for this repository is `v-old-0.0.42`, dated 2026-05-14. The version name includes `old`, which is consistent with the README's description of this as the former implementation, although the release list alone does not define compatibility or upgrade guarantees. The README does not document a migration procedure from this repository to `hylo-new`.

The Apache-2.0 license permits use and modification under its terms, but this review does not provide legal interpretation. Contributors must also account for the cost of Swift 6.2, LLVM 20, submodules, platform-specific symbolic links, `pkg-config`, and possible Visual Studio configuration. Toolchain changes are not interchangeable across major LLVM versions, according to the README, so an upgrade can require rebuilding the environment rather than simply replacing a binary.

Editorial conclusion

Adopt this repository if you need to study or build the former Hylo compiler and have Swift 6.2 plus LLVM 20 available. Do not choose it as the default target for new Hylo work without first checking the README's redirect to hylo-new. Verify the compiler source, submodule state, LLVM installation, and platform configuration first, because this repository is no longer where most Hylo development effort is directed.

Frequently asked questions

Official sources

1. hylo-lang/hylo on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases