elf-magic ✨
⚠️ UNDER CONSTRUCTION ⚠️
This crate is in active development and is not well tested yet.
APIs may change without notice. Use at your own risk.
It just works, don't ask how.
Actually, fine - here's how it works: You get a build.rs one-liner that generates compile-time ELF exports for every Solana program in your workspace.
Stop wrestling with Solana program builds. elf-magic automatically discovers all your programs, builds them, and generates clean Rust code so your ELF bytes are always available as constants.
Quick Start
Add to Existing Workspace
# Create an ELF crate in your workspace
# Add to my-elves/Cargo.toml
# Add to my-project-elves/build.rs
) {
What You Get
After building, your ELF crate exports generated constants for every Solana program in your workspace:
On your first build, you'll see:
)
// Generated in src/lib.rs - never edit this file!
pub const TOKEN_MANAGER_ELF: & = include_bytes!;
pub const GOVERNANCE_ELF: & = include_bytes!;
Use your programs anywhere:
use ;
// Deploy, test, embed - whatever you need
let program_id = deploy_program?;
How It Works
The one-liner sounds too good to be true, but here's the magic:
- Program Discovery:
cargo metadatatells us about every crate in your workspace - Solana Detection: We filter for crates with
crate-type = ["cdylib"]- those are your Solana programs - Build Orchestration: Run
cargo build-sbfon each program automatically - Code Generation: Transform program names into clean Rust constants and generate your entire
src/lib.rs - Incremental Builds: Set up
cargo:rerun-if-changedso rebuilds only happen when needed
Behind the scenes:
- 🔍 Auto-discovery:
cargo metadatafinds all workspace members - 🎯 Smart filtering:
crate-type = ["cdylib"]identifies Solana programs - 🔨 Automatic building:
cargo build-sbfruns when source changes - 📝 Code generation: Program names become
PROGRAM_NAME_ELFconstants - ⚡ Incremental: Only rebuilds what changed
- 🧙♂️ Config Optional: Works with any workspace layout
Workspace Structure
Works with any layout, but here's what the template gives you:
my-workspace/
├── Cargo.toml # Workspace root
├── my-elves/ # Generated ELF exports
│ ├── build.rs # One-liner magic ✨
│ └── src/lib.rs # Auto-generated, don't edit
└── programs/
├── token-manager/ # Your Solana programs
├── governance/
└── whatever-else/
Advanced Usage
Need more control over which programs get built? Configure your ELF crate's Cargo.toml:
# my-project-elves/Cargo.toml
[]
= ["programs/*", "examples/simple-*"]
= ["programs/deprecated-*", "examples/broken-*"]
Common patterns:
# Separate production and examples
[]
= ["programs/*"]
= ["examples/*", "tests/*"]
# Only specific programs
[]
= ["programs/token-manager", "programs/governance"]
# Everything except broken ones
[]
= ["programs/experimental-*"]
Without any config, elf-magic discovers and builds everything - perfect for getting started. Add config only when you need it.
Why elf-magic? The tl;dr
Before:
- Run
cargo build-sbfmanually for each program - Hard-code filesystem paths to .so files in your code
- Get runtime panics when files aren't where you expect
- Context-switch between
cargoand Solana-specific tooling - Remember which programs need rebuilding and when
- Hunt down missing program files across environments
After:
Your ELF bytes are always available as clean, typed constants. No more bespoke build commands. No more tracking file paths. Just cargo build and everything works.
The magic happens behind the scenes - elf-magic runs cargo build-sbf when needed, but you never have to think about it.
Why elf-magic? The manifesto
The Real Problem: Missing Engineering Practices
Solana development suffers from a tooling gap that makes essential software engineering practices unnecessarily difficult:
Testing is broken. Most projects can't easily unit test their program interactions because ELF bytes aren't available at compile time. Developers resort to:
- Hard-coded file paths that break in CI
- Runtime discovery that fails unpredictably
- Skipping integration tests entirely
Benchmarking is impossible. You can't benchmark program deployment or interaction patterns when your toolchain can't reliably find program binaries.
Auditing is compromised. Security reviews need to verify the exact program bytes being deployed, but most projects have fragile, bespoke build processes that obscure this.
The Developer Experience Tax
Every Solana project pays this tax:
- Context switching between
cargoand Solana-specific commands - Runtime panics when files aren't where expected
- Environment-specific builds that work locally but fail in CI
- Fragile deployment scripts that break when paths change
elf-magic Fixes This
Clear Rust dependencies. Your program binaries become compile-time constants with normal Rust visibility and dependency management.
Standard toolchain. Just cargo build, cargo test, cargo bench. No special commands, no custom scripts.
Reliable CI/CD. Deterministic builds that work the same everywhere.
Better testing. Write unit tests that actually test your program interactions:
Professional auditing. Auditors can verify exact program bytes with confidence.
elf-magic doesn't just automate builds - it enables the software engineering practices that make Solana projects reliable, testable, and maintainable.
Requirements
- Rust toolchain
- Solana CLI tools (
cargo install-sbfmust work) - Workspace with Solana programs (crates with
crate-type = ["cdylib"])