Drop the append-only versioning doctrine; document the version script

Module APIs and the library's exported ABI are versioned and retired
deliberately: a break ships as a new table version or a new symbol
version node, and consumers judge the versions they are handed.

Document src/libdpm-core.map — what it pins, what belongs in it, and
how a generation is retired — and declare DPM_CORE_0.1 as the shape
the next retired node takes.
This commit is contained in:
2026-08-14 02:35:03 -04:00
parent 298f4d5afe
commit 267529bee3
7 changed files with 164 additions and 118 deletions

View File

@@ -6,11 +6,13 @@
- CMake 3.22 or later
- Make
- Doxygen (optional, for the code reference)
- pdflatex and makeindex (optional, for the PDF code reference)
- `pdflatex` and `makeindex` (optional, for the PDF code reference)
The library itself depends only on libc and libstdc++, so it builds and runs on a minimal system.
## Building for development
## Development Builds
Configure a build tree and compile it:
```
cmake -B <build-dir> -DCMAKE_BUILD_TYPE=Debug
@@ -25,17 +27,17 @@ Artifacts land in:
<build-dir>/modules/info.so the bundled info module
```
The dpm binary built here finds the locally built libdpm-core.so on its own — an embedded library search path points it at the lib/ directory next to it in the build tree, so running it directly uses the library you just built with nothing to set up first. This is only the default: LD_LIBRARY_PATH takes precedence over the embedded path, so the binary can be pointed at any other libdpm-core, including the system-installed one.
The `dpm` binary built here finds the locally built `libdpm-core.so` on its own — an embedded library search path points it at the `lib/` directory next to it in the build tree, so running it directly uses the library you just built with nothing to set up first. This is only the default: `LD_LIBRARY_PATH` takes precedence over the embedded path, so the binary can be pointed at any other libdpm-core, including the system-installed one.
### Running the tests
### Automated Testing
```
ctest --test-dir <build-dir> --output-on-failure
```
This runs the API test binary (which exercises the full load-time validation matrix against the fixture modules in tests/fixtures/) and the CLI end-to-end tests.
This runs the API test binary (which exercises the full load-time validation matrix against the fixture modules in `tests/fixtures/`) and the CLI end-to-end tests.
### Running the CLI from the build tree
### Manual Execution
The build tree plus the test fixtures form a complete self-contained environment; no installation is required. Point the CLI at local paths with its override flags:
@@ -43,11 +45,11 @@ The build tree plus the test fixtures form a complete self-contained environment
<build-dir>/bin/dpm --config-dir ./tests/fixtures/conf --module-path <build-dir>/modules info version
```
The flags --config-dir, --module-path, --root, and --log-level each redirect the corresponding system default; --root sets the target root that package-operation modules act on.
The flags `--config-dir`, `--module-path`, `--root`, and `--log-level` each redirect the corresponding system default; `--root` sets the target root that package-operation modules act on.
## Building, testing, and installing a release
## Release Builds
One build tree carries the whole sequence — the test suite builds and runs in any configuration, so the artifacts that get tested are the artifacts that get installed:
One build tree carries the whole sequence, so the artifacts that get tested are the artifacts that get installed:
```
cmake -B <build-dir> -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr
@@ -56,7 +58,25 @@ ctest --test-dir <build-dir> --output-on-failure
cmake --install <build-dir>
```
This is the packaging flow: configure once, build once, test what was built, install what was tested. Omit -DCMAKE_INSTALL_PREFIX=/usr for a /usr/local install. Under the install prefix this installs:
This is the packaging flow: configure once, build once, test what was built, install what was tested.
### Automated Testing
The test suite builds and runs in any configuration, so a release tree is tested by the same command a development tree is:
```
ctest --test-dir <build-dir> --output-on-failure
```
Running it between the build and the install step is what makes the sequence above a packaging flow rather than four unrelated commands.
### Installation
```
cmake --install <build-dir>
```
Omit `-DCMAKE_INSTALL_PREFIX=/usr` at configure time for a `/usr/local` install. Under the install prefix this installs:
```
bin/dpm the CLI
@@ -65,6 +85,4 @@ lib/dpm/modules/info.so the bundled info module
include/dpm/ the public header
```
The libdpm-core configuration installs to /etc/dpm/conf.d/core.conf regardless of prefix.
The libdpm-core configuration installs to `/etc/dpm/conf.d/core.conf` regardless of prefix.