Christopher M. Punches
da35fe4758
clean was deleting the generated build system along with the artifacts — CMakeCache.txt, the makefiles, CMakeFiles/, the CMake file API directory, and the CTest configuration. That left the build directory unconfigured after every clean, so an IDE reading its target list from the file API lost every target until the project was reloaded. clean now removes only what the build produced. Also writes CTest's scratch directory into DartConfiguration.tcl so a bare ctest and IDE test discovery use it too, not just build-driven runs. BUILD.md no longer lists libdl as a dependency; glibc 2.34 merged it into libc, so nothing links against it. The code-reference section moves to its own DOCUMENTATION.md. The fixture config logged at ERROR while the info module emits its output at INFO, so the CLI invocation BUILD.md documents exited 0 and printed nothing. The fixture now logs at INFO and the documented command works as written. OVERVIEW.md describes what DPM is, how core routes and validates modules, and why the architecture takes the shape it does. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
71 lines
2.6 KiB
Markdown
71 lines
2.6 KiB
Markdown
# Building DPM Core
|
|
|
|
## Prerequisites
|
|
|
|
- GCC/G++ supporting C++20
|
|
- CMake 3.22 or later
|
|
- Make
|
|
- Doxygen (optional, for the 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
|
|
|
|
```
|
|
cmake -B <build-dir> -DCMAKE_BUILD_TYPE=Debug
|
|
cmake --build <build-dir>
|
|
```
|
|
|
|
Artifacts land in:
|
|
|
|
```
|
|
<build-dir>/bin/dpm the CLI
|
|
<build-dir>/lib/libdpm-core.so the core library
|
|
<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 core 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 core, including the system-installed one.
|
|
|
|
### Running the tests
|
|
|
|
```
|
|
ctest --test-dir <build-dir> --output-on-failure
|
|
```
|
|
|
|
This runs the core 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
|
|
|
|
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:
|
|
|
|
```
|
|
<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.
|
|
|
|
## Building, testing, and installing a release
|
|
|
|
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:
|
|
|
|
```
|
|
cmake -B <build-dir> -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr
|
|
cmake --build <build-dir>
|
|
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:
|
|
|
|
```
|
|
bin/dpm the CLI
|
|
lib/libdpm-core.so the core library
|
|
lib/dpm/modules/info.so the bundled info module
|
|
include/dpm/ the public header
|
|
```
|
|
|
|
Core configuration installs to /etc/dpm/conf.d/core.conf regardless of prefix.
|
|
|
|
|
