fold/docs/BUILDING.md
trvon 57f13a7643
docs(build): canonical BUILD.md with per-platform deps
Top-level BUILD.md so users see the dependency list (libz3-dev,
libclang-dev, llvm-dev, etc.) without spelunking docs/. Lists apt
package names for Ubuntu/Debian, dnf names for Fedora/RHEL, and
brew names for macOS — kept in sync with docker/Dockerfile.linux-
validate, which is the executable spec.

- README points at BUILD.md instead of docs/BUILDING.md.
- docs/BUILDING.md trimmed to radare2 vendoring notes only (the
  topic that didn't belong in a top-level quick-start).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-24 18:11:31 -04:00

50 lines
1.8 KiB
Markdown

# Building (radare2 integration notes)
The canonical build instructions — dependencies, per-platform install
commands, environment overrides — live in **[../BUILD.md](../BUILD.md)**.
This file keeps the radare2 vendoring and binary-backend integration
notes that don't belong in the top-level quick-start.
## radare2 binary backend
The binary backend links against radare2's `libr_core` when
`pkg-config` can find `r_core.pc` (for example under
`/usr/local/lib/pkgconfig` or Homebrew's prefix). If the development
package is not present, fold still builds and uses the `r2`
command-line fallback at runtime.
```sh
# Require linked radare2 support at configure time
meson setup build/release --reconfigure -Dradare2=enabled
# Disable linked radare2 support and rely on the CLI fallback
meson setup build/release --reconfigure -Dradare2=disabled
```
Vendoring radare2 should be done through a build-system dependency
path (Meson subproject/wrap or pinned external source in CI), not by
committing the full upstream tree into `src/`. fold is GPL-3.0-only,
so radare2's GPL-compatible builds are license-compatible, but the
upstream project is large and has plugin ABI concerns. The preferred
clean integration is:
1. Build/pin radare2 in CI or a Meson subproject.
2. Expose `r_core.pc` to fold's Meson configure step.
3. Compile fold with `-Dradare2=enabled`.
This keeps the binary backend using stable `libr_core` APIs while
avoiding a large vendored source tree in normal checkouts.
## Binary backend integration test
The optional `binary_backend` integration test uses radare2 and a
real binary. Defaults to `/usr/bin/curl` when available, can be
redirected via:
```sh
FOLD_TEST_BINARY=/path/to/binary meson test -C build/release binary_backend
```
The test skips itself when no suitable binary or `r2` command is
present.