Chapter 17: Crates, Modules, and Packages

Introduction

In C and C++, managing large projects typically involves dividing code into multiple source files (.c, .cpp) and using header files (.h, .hpp) to declare shared interfaces (functions, types, macros). While this approach is fundamental, it presents challenges: potential global namespace collisions, complex build system configurations (e.g., Makefiles, CMake) needed to track dependencies, and the exposure of internal implementation details through header files required for compilation.

Rust addresses code organization and dependency management with a more explicit and hierarchical system built on three core concepts: packages, crates, and modules.

• Package: The largest organizational unit, managed by Cargo. A package bundles one or more crates to provide specific functionality. It’s the unit of building, testing, distributing, and dependency management via its Cargo.toml manifest file.
• Crate: The smallest unit of compilation in Rust. rustc compiles a crate into either a binary executable or a library (.rlib, .so, .dylib, .dll). A package contains at least one crate, known as the crate root.
• Module: An organizational unit within a crate. Modules form a hierarchical namespace (the module tree) and control the visibility (privacy) of items like functions, structs, enums, traits, and constants.

This chapter delves into Rust’s module system. We’ll explore how code is structured within crates using modules, how packages group crates, how workspaces manage multiple related packages, and how Cargo orchestrates the entire process. We assume basic familiarity with Cargo from previous chapters; a more detailed examination of Cargo’s features will follow later.