Project Structure

Module ownership, stable public include paths, and the build-time dependency graph.

Top-Level Layout

sharp-runtime/
├── CMakeLists.txt          # Root component selection and build options
├── cmake/                  # Component registration and boundary validation
├── modules/                # 40 self-contained runtime modules
├── tests/integration/      # Tests which genuinely span modules
├── vendor/                 # Third-party dependencies
├── scripts/                # Component checks and test runner
├── docs/                   # Component guides and generated catalogue
├── README.md               # Project overview and integration quick start
├── CLAUDE.md               # Architecture and portability policy
├── Doxyfile                # Doxygen configuration
└── build/                  # Generated build artifacts (not committed)

modules/ — Runtime Ownership

The physical layout is module-based. Every module owns its public headers, implementation sources, tests, and CMake declaration:

modules/text-json/
├── CMakeLists.txt
├── README.md
├── include/System/Text/Json/  # Consumer-facing header paths
├── src/
└── tests/System/Text/Json/

Consumer include spellings are stable: code still writes #include <System/Text/Json/JsonDocument.hpp>. Linking the appropriate SharpRuntime::* target supplies the module include root.

Module groups

Headers, Sources, and Tests

Module ownership, rather than namespace prefixes, defines physical placement. A header may be included as System/IO/Stream.hpp while living in modules/io/include/. Header-only components have no implementation sources; static components keep their sources in the local src/ directory.

There are 983 public headers and 369 component-owned test sources. Only cross-module scenarios live in tests/integration/.

CMake and Dependency Boundaries

Each module's CMakeLists.txt declares whether its dependencies are public, private, or test-only. Public dependencies propagate the necessary include roots to consumers; private dependencies do not. The component validator checks source ownership, include relationships, dependency visibility, and graph cycles.

See Components & Modules for the public component catalogue and Build System for selection examples.

Third-Party Code