13 releases (7 breaking)
| 0.8.1 | Jan 18, 2026 |
|---|---|
| 0.7.1 | Dec 9, 2025 |
| 0.6.0 | Nov 8, 2025 |
| 0.4.1 | May 19, 2025 |
| 0.1.0 | Sep 7, 2024 |
#204 in Build Utils
601 downloads per month
Used in cicero
110KB
2K
SLoC
Cicero Distribution
Need to pack multiple files into a distribution?
Cicero provides an API for specifying the file structure and then deferring to your functions to provide the contents:
#[cfg(feature = "build")] {
use std::{fs, path::Path};
use cicero_distribution::{Distribution, build::Target, bundle::dir::DirBundler};
use cicero_path::repo_path;
fn main() -> cicero_core::Result<()> {
let distribution = Distribution::new("myproject")?;
let target = Target::x86_64_unknown_linux_gnu;
distribution
.add_file_from_path("README.md", repo_path!("README.md"))?
.add_file("myproject", |file| build_backend_executable(file, &target))?;
distribution
.dir("public")?
.add_all(|dir| build_frontend(dir))?;
let distribution_dir = distribution.bundle(DirBundler)?;
Ok(())
}
fn build_frontend(out_dir: &Path) -> cicero_core::Result<()> {
let build_out_dir: &Path = unimplemented!();
fs::rename(build_out_dir, out_dir)?;
Ok(())
}
fn build_backend_executable(out_file: &Path, target: &Target) -> cicero_core::Result<()> {
let build_out_file: &Path = unimplemented!();
fs::rename(build_out_file, out_file)?;
Ok(())
}
}
Advantages to this approach:
- File structure is documented and trivially correct.
- Conflicts due to two code locations modifying the same files are practically eliminated.
- Obvious where to jump into the code to change a portion of the distribution.
- Less path wrangling. Your function has the complete path passed to it. No need to modify it further.
- Your functions become naturally testable. You can pass a temporary path (e.g. from
assert_fs) instead and assert on that.
Mind that this API may still see larger changes, as more features are implemented.
Dependencies
~7–15MB
~227K SLoC