Crates.io | tinyrick |
lib.rs | tinyrick |
version | 0.0.14 |
source | src |
created_at | 2018-10-21 16:14:19.991962 |
updated_at | 2024-01-15 04:09:03.140413 |
description | a freeform Rust build system |
homepage | https://github.com/mcandre/tinyrick |
repository | |
max_upload_size | |
id | 91845 |
size | 24,113 |
.---. ^
o{__ω__ o{ ^0^ -Let me out!
~~ ( // *|* \xx\) xx`|'
= = xxxx&x ' `
$ cd example
$ tinyrick
running 1 test
test smoketest ... ok
$ tinyrick -h
Usage: tinyrick [options]
Options:
-l, --list list available tasks
-h, --help print usage info
-v, --version print version info
I'm tinyrick (TINYRICK!) and I build Rust projects. With tinyrick, you configure your build in the same normal Rust code as the rest of your project. Or keep picking your nose with make, it's up to you.
Look at my pants! tinyrick! You think my pants are one size fits all? No, of course not! So get the pants that fit you. Get a tinyrick.rs
that fits your workflow. Task dependency trees, get em while they're hot! Segfaults, get em while they're not. Smarter, butter, faster, stranger.
Don't shell out, lib out. Your build is more portable that way. tinyricktinyricktinyrick. If you look closely, that last period is actually a micro rick rendered in ASCII; even tinier tinyrick!
https://crates.io/crates/tinyrick
https://docs.rs/tinyrick/latest/tinyrick/
BSD-2-Clause
asdf reshim
after each Rust application binary installation)Write some tasks in a tinyrick.rs
build configuration script at the top-level directory of your Rust project:
fn banner() {
println!("{} {}", env!("CARGO_PKG_NAME"), env!("CARGO_PKG_VERSION"));
}
fn test() {
tinyrick::exec!("cargo", &["test"]);
}
fn build() {
tinyrick::deps(test);
tinyrick::exec!("cargo", &["build", "--release"]);
}
fn publish() {
tinyrick::exec!("cargo", &["publish"]);
}
fn clean() {
tinyrick::exec!("cargo", &["clean"]);
}
fn main() {
tinyrick::phony!(clean);
tinyrick::wubba_lubba_dub_dub!(build; banner, test, publish, clean);
}
Now, wire up the tinyrick command line interface by configuring your top-level Cargo.toml
:
[package]
name = "derpmobile"
description = "hyperadvanced derpmobiles"
version = "3.1.4"
[dependencies]
tinyrick = { version = "0.0.14", optional = true }
[features]
letmeout = ["tinyrick"]
[[bin]]
name = "tinyrick"
path = "tinyrick.rs"
required-features = ["letmeout"]
Launch a terminal session in your project directory. Install and run the tinyrick tool:
$ cargo install tinyrick
$ tinyrick
Watch how he behaves... I hope tinyrick is practicing good manners :P
What happens when you run:
tinyrick banner
?tinyrick test
?tinyrick clean
?tinyrick build
?tinyrick -h
?tinyrick --list
?VERBOSE=1 tinyrick build
?I bet the freakin' moon explodes if you run VERBOSE=1 tinyrick build build build
! (Hold onto your pants~)
Where are my pants? Let's break down the code so far:
fn name() { ... }
declares a task named name
.deps(requirement)
caches a dependency on task requirement
.exec!(...)
spawns raw shell command processes.VERBOSE=1
enables command string emission during processing.phony!(...)
disables dependency caching for some tasks.wubba_lubba_dub_dub!(default; ...)
exposes a default
task and some other tasks to the tinyrick command line.letmeout
is a feature gate, so that neither the tinyrick package, nor your tinyrick binary escape with your Rust package when you tinyrick publish
.Just because the tinyrick library offers several supremely convenient macros for executing shell commands doesn't mean that you should always shell out. No way, man!
Whenever possible, use regular Rust code, as in the banner()
example. There's like a ba-jillion crates of prewritten Rust code, so you might as well use it!
For more details on developing tinyrick itself, see DEVELOPMENT.md.