Back

So, in Rust, a crate is a compilation unit. In other words, you got

src/main.rs: use mod_a::foo;
src/mod_a.rs: pub fn foo() {}

you can build it with "rustc main.rs".

Which lead to a very natural question: do we even need cargo? How hard would it be to build a fairly complex 3d game without cargo?

2/n

While rustc manage modules, we still need external dependencies. It works in a super straightforward way:

crate_a:
lib.rs: pub fn f() {}

main.rs:
use crate_a::f;
fn main() { f() };

Just two commands to make it work:

rustc --crate-type lib crate_a/lib.rs
rustc --extern crate_a=libcrate_a.rlib main.rs

3/n

proc macros works in exactly the same way, just --crate-type proc_macro first, and an --extern crate_with_a_macro=crate.so second.

So, its easy to link with a local dependency, its easy to use proc macros.

Imagine if we got a game with all the dependencies living in /deps.
Some proc-macro-heavy json parser stuff, some window opening abstractions, some 3d rendering.

How hard would it be to build it?

4/n

I rolled a custom, very barebone, very stupid, "dependency manager".

And it works!! I

Its a rust library, it is called Sloop, it can be linked with a game's "build.rs" file.

"build.rs" looks like this: https://github.com/not-fl3/sloop-example-projects/blob/main/miniquad_triangle/build.rs

And thats the whole sloop source: https://github.com/not-fl3/sloop/blob/master/sloop.rs

5/n

Thats how sloop boostrapping looks like:

Building sloop itself:

> rustc --crate-type lib sloop.rs

Building a builder program:

> rustc --extern sloop=libsloop.rlib build.rs

Building the game:
> ./build

I made a rustup-style shell script that hides it all under just one single "sloop" command. Just write your build.rs and call "sloop" like its a real thing!

6/n

A few words on why, or what I don't like about cargo?

- underpowered cargo subcommands. cargo-the-crate is a 250-dependency monster with very unstable API

- overpowered build.rs. I would prefer a decisions on invoking custom code/shell scripts to be on the top level, not on a sub-dependency level

- too easy to add subdependencies. There is something in "Simple rule: include files should never include include files."
(c) Rob Pike"" http://www.lysator.liu.se/c/pikestyle.html