cl-asdf-system

ASDF system definitions standardize Common Lisp project structure by organizing defsystem declarations with consistent metadata, component hierarchies, dependency management, and semantic versioning. This ensures reproducible builds, proper dependency resolution, and compatibility with package managers like Quicklisp across small libraries and large multi-module systems.

An .asd file should declare the system name, version, author, license, and description in defsystem, then organize components using serial and non-serial ordering for proper dependency sequencing. Include main dependencies, conditional feature dependencies, test components, and metadata like long descriptions and URLs for clarity and Quicklisp submission.

ASDF supports primary and weak dependencies specified in defsystem, plus feature-driven conditional components. Use :depends-on for required modules, :weakly-depends-on for optional ones, and :if-feature to load components only when features are enabled, enabling modular design across both small and large systems.

Yes, ASDF integrates test components directly into system definitions. Define a separate test system or add test components within defsystem, connecting them to testing frameworks like Rove. This enables ASDF to run tests as part of the build workflow and supports Quicklisp test integration.

Serial component ordering loads files sequentially with each file depending on previous ones, ensuring strict evaluation order. Non-serial ordering allows independent compilation, reducing build time. Choose serial for interdependent code and non-serial for modular components to balance correctness and performance.

Use regular dependencies for required libraries that must load before your system. Use weak dependencies for optional enhancements that gracefully skip if unavailable, preventing build failures when optional packages aren't installed while maintaining system functionality and modularity.