Aegisub's repository documents the build, not the subtitle editing

A subtitle editor whose repository text is almost entirely build instructions

Aegisub is a cross-platform subtitle editor written in C++, and it ships its own Meson build rather than a configure script. What the repository says about the program itself is thin. There is no feature list, no enumeration of subtitle formats, and no description of the editing interface anywhere in the README. Binaries live elsewhere: the opening line sends readers to aegisub.org for them, the bug tracker is the issue tracker at https://github.com/TypesettingTools/Aegisub/issues, and support runs through a Discord server and IRC on irc://irc.rizon.net/aegisub. Every constraint the text does spell out is about compiling, not about typing. If your decision depends on whether Aegisub handles the container or format you work in, the repository will not answer it, and you have to judge the editor from the running application. One thing is stated with no build context at all: the primary language is C++, and the default branch is master.

Windows: configure with Meson from the x64 Native Tools prompt

Windows has the shortest documented path of the three platforms. Four prerequisites are required: Visual Studio, where the Community edition of any recent version works as long as the Windows SDK is included, plus Python 3, Meson and CMake. Three more are optional and matter only when you package: msgfmt for the translations, InnoSetup through iscc.exe for the regular installer, and 7zip through 7z.exe. Everything else is either stored in the repository or arrives as a submodule.

git clone https://github.com/TypesettingTools/Aegisub.git
meson build -Ddefault_library=static
cd build
ninja

Run the configure step from the Visual Studio x64 Native Tools Command Prompt, and the binary that appears in the build directory is aegisub.exe. Two further targets follow a successful build, and both assume a working internet connection plus those optional programs.

ninja win-installer
ninja win-portable

Compare that with the other two platforms, because the difference is easy to skim past. Windows configures with a bare `meson build` and finishes with `ninja`, while the Linux and macOS recipes configure with `meson setup` and finish with `meson compile -C build`. Static linking is requested on Windows and on Linux alike through -Ddefault_library=static, yet the short personal-use macOS path never asks for it.

macOS bottles can outrun the default deployment target

Xcode and its command-line tools are the stated macOS requirement, and the text leaves the version deliberately vague. For personal use, pip and homebrew cover almost every dependency, with three exported variables pointing the compiler at ICU under /usr/local/opt/icu4c. On Apple Silicon, the same three lines need /usr/local replaced by /opt/homebrew.

pip3 install meson      # or brew install meson if you installed Python via brew
brew install cmake ninja pkg-config  libass boost zlib ffms2 fftw hunspell uchardet
export LDFLAGS="-L/usr/local/opt/icu4c/lib"
export CPPFLAGS="-I/usr/local/opt/icu4c/include"
export PKG_CONFIG_PATH="/usr/local/opt/icu4c/lib/pkgconfig"

The homebrew route carries a catch the text states plainly: bottles target the macOS version they were built for, which can be newer than the default deployment target Aegisub builds against. That is why the local disk image recipe reads the running system version into the deployment target and asks for an ad-hoc signature instead of a real one.

deployment_target="$(sw_vers -productVersion)"
meson setup build_static \
  -Ddefault_library=static \
  -Dbuildtype=debugoptimized \
  -Dbuild_osx_bundle=true \
  -Dmacos_deployment_target="${deployment_target}" \
  --force-fallback-for=boost
meson compile -C build_static
meson test -C build_static --verbose
export AEGISUB_BUNDLE_SIGNATURE=-
meson compile osx-bundle -C build_static
meson compile osx-build-dmg -C build_static

Read that as a sequence of concessions rather than a clean package recipe. debugoptimized replaces a tuned build, boost is forced to fall back instead of using a bottle, AEGISUB_BUNDLE_SIGNATURE=- leaves the bundle unsigned, and the tests are run explicitly before anything is bundled. The disk image it produces is for development and personal use on that macOS version; the official packages are built in CI from source-built dependencies and signed through the process described in docs/developer_docs.md.

Linux needs a long package list and forbids LTO outright

The Debian-based instructions compress a large dependency table into one line. Install it on Ubuntu 24.04 and you have everything the configure step looks for.

sudo apt install build-essential pkg-config meson ninja-build gettext intltool libfontconfig1-dev libass-dev libboost-chrono-dev libboost-locale-dev libboost-regex-dev libboost-system-dev libboost-thread-dev zlib1g-dev wx3.2-headers libwxgtk3.2-dev icu-devtools libicu-dev libpulse-dev libasound2-dev libopenal-dev libffms2-dev libfftw3-dev libhunspell-dev libuchardet-dev libcurl4-gnutls-dev libgl1-mesa-dev libgtest-dev libgmock-dev libportal-gtk3-dev

Two entries in the underlying table are alternatives rather than hard requirements: pkg-config or pkgconf, and libcurl4-openssl-dev or libcurl4-gnutls-dev. WxWidgets is pinned at 3.2 by wx3.2-headers and libwxgtk3.2-dev, audio shows up three separate times through libpulse-dev, libasound2-dev and libopenal-dev, and libgl1-mesa-dev carries the rendering path. The README does not map any single library to a named feature of the editor.

meson setup build --prefix=/usr/local --buildtype=release --strip -Dsystem_luajit=false -Ddefault_library=static
meson compile -C build
meson install -C build --skip-subprojects luajit

The prefix is yours to choose, and -Dsystem_luajit=false is the switch that makes the build use the vendored Lua runtime instead of the distribution's. One restriction is absolute: Aegisub cannot be built with LTO, with the reason tracked in issue 290, and the text offers no workaround beyond not asking for it. Rendering carries a second condition. Aegisub reaches OpenGL through wxWidgets, so running directly on Wayland needs wxWidgets built with EGL enabled; without it the application falls back to X11 on its own, which on a Wayland session means Xwayland.

Packaging switches off the tests that guard libstdc++

The distribution recipe is the block worth reading twice, because it disables the suite that would otherwise catch one of the project's own runtime requirements.

meson subprojects download luajit              # Or use the tarball
meson subprojects packagefiles --apply luajit

meson setup builddir --wrap-mode=nodownload --prefix=/usr --buildtype=release -Dsystem_luajit=false -Ddefault_library=static -Dtests=false

meson compile -C builddir
meson install -C builddir --skip-subprojects luajit

That configure line ends in -Dtests=false. Two paragraphs earlier, the text says Aegisub needs libstdc++ 6.0.32 or later when linked against libstdc++, that the project's tests detect the problem behind that requirement, and that a packager who does not run tests has to make sure the library version is recent enough. So the flag that speeds up a distribution build is the same flag that removes the only automated guard on a runtime floor, and the substitute is a manual check by whoever builds the package. The first two lines exist because of --wrap-mode=nodownload: with downloads disabled, Meson has to find the LuaJIT sources locally before it can configure at all.

LuaJIT must carry Lua 5.2 compatibility, and three paths supply it

Aegisub depends on LuaJIT and requires it to be built with Lua 5.2 compatibility enabled. The text is blunt about the consequence for packagers: most distributions compile LuaJIT without that flag, and issue 239 carries the longer discussion. The project's answer is a meson subproject for LuaJIT that can be linked statically in a 5.2-compatible build, with the downloaded subproject already placed inside the source tarballs for anyone whose build system may not fetch sources.

That leaves three concrete routes. Build against the distribution's own LuaJIT, which works only if that copy was compiled with the compatibility flag the text says is usually missing. Download the subproject with meson subprojects download luajit and configure with -Dsystem_luajit=false, which is the flag the everyday Linux instructions already carry. Or, where no network is allowed at build time, apply the vendored files with meson subprojects packagefiles --apply luajit and add --wrap-mode=nodownload so Meson refuses to fetch anything.

Both example installs then end with --skip-subprojects luajit, and neither says in prose what that flag changes in the installed tree. A packager copying the line is trusting an undocumented flag, in the same recipe that already turns the test suite off.

A root tree of directories the README never explains

The top level is short enough to read in one pass: .editorconfig, .gitattributes, .github/, .gitignore, README.md, then the directories automation/, docs/, libaegisub/, packages/, po/, src/, subprojects/, tests/ and tools/, with meson.build and meson_options.txt sitting beside them. Most of it goes undescribed. libaegisub/ stands next to src/ as a separate library target, and the build is configured through meson_options.txt, yet not one option name is listed in the repository text beyond the ones passed on the command lines above. automation/, packages/ and tools/ are never explained: whether automation holds the scripting side, whether packages carries per-platform install recipes for the platforms the build docs name, the text does not say. tests/ is the one directory whose purpose is confirmed indirectly, by the libstdc++ requirement and by the -Dtests=false switch.

Every source file carries a GPL-compatible BSD-style licence, the official Windows and OS X builds are GPLv2 because they include fftw3, and the file at the root is spelled LICENCE while the licence classification points at a LICENSE file, so follow LICENCE and then the individual source files.

Binaries come from the homepage, bugs come to the issue tracker

None of the build material is where most people should start. The first line of the README points binaries and general information to aegisub.org, and that homepage is the only distribution channel the repository names. No package manager recipe exists for any platform: the apt line in the build docs installs compilers and headers, not Aegisub. Bugs belong in the issue tracker, and the two threads the text cites for packaging problems, issue 290 on LTO and issue 239 on LuaJIT, confirm that this is where distribution questions get handled.

The last push landed on 2026-10-06, one day after the v3.5.0 tag dated 2026-10-05, which followed a 3.4.2 tag from 2025-01-13 by a long gap. Two things an evaluator would look for are simply absent. The repository text does not document rollback, so there is no stated procedure for reverting an installed build to an earlier version. It also never lists which subtitle formats the editor reads or writes, which is the first question anyone adopting a subtitle editor should ask. The only other document linked is docs/developer_docs.md, and the single anchor quoted from it points at the macOS signing process rather than at editing behaviour.

Editorial conclusion

Aegisub suits people who already know subtitle work and want to build or package the editor themselves; anyone picking an editor for daily use learns nothing from this repository text and has to judge the application directly, because no package recipe for Windows, macOS or Linux exists in it. Before packaging, check the two things that constrained the authors: LuaJIT compiled with Lua 5.2 compatibility, and libstdc++ 6.0.32 or later, since configuring with -Dtests=false removes the only automated check of the second.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. TypesettingTools/Aegisub on GitHub