Package Types
Manifest Version 1 accepts exactly four case-sensitive package types:
| Type | Manifest value | rux build | rux run | Native artifact |
|---|---|---|---|---|
| Executable | "Executable" | Yes | Yes | See below |
| Shared library | "SharedLibrary" | Yes | No | See below |
| Static library | "StaticLibrary" | Yes | No | See below |
| Source library | "SourceLibrary" | No | No | None |
Program, Library, and Source are retired spellings and are invalid; there are no compatibility aliases.
An Executable must define Main(). Its artifact is Name.exe on Windows and Name on ELF targets and macOS.
A SharedLibrary exports its public symbols. It produces Name.dll and the Name.lib import library on Windows, libName.so on ELF targets, or libName.dylib on macOS.
A StaticLibrary preserves unresolved external references for the final native link. It produces Name.lib on Windows or libName.a on ELF targets and macOS.
A SourceLibrary is checked on its own and compiled directly into whichever package depends on it. It has no standalone build or run artifact.
SharedLibrary or StaticLibrary does not make the consuming package link its binary artifact yet.The compile-time #build.outputKind value is OutputKind::Executable, SharedLibrary, StaticLibrary, or SourceLibrary when a package is checked on its own. Source compiled as a dependency observes the consuming package's output kind.
For Rux 0.4.0, only SourceLibrary packages can be packed or published to a registry. Shared and static libraries are local native artifacts in this release.
Overview
How Rux packages are built, described, published, and consumed — package types, the Rux.toml manifest, dependencies, namespaces, API tokens, publishing to the registry, versioning, and yanking.
Yanking
Yanking withdraws a published version from new dependency resolution while leaving it available to builds that already depend on it. It is the way to retire a release that turned out to be broken, insecure, or published by mistake.