Third-party dependencies
This directory is for mostly external building blocks that are built or linked by mars-nwe but are not project-specific service forks. Code here should normally be accessed through a mars-nwe facade or subsystem instead of being included from endpoint/provider code directly.
yyjson
The salvage metadata backend uses the bundled yyjson submodule for JSON read/write support. The submodule is required and is linked statically into the mars-nwe server targets that use salvage metadata.
Setup:
git submodule update --init --recursive third_party/yyjson
CMake expects third_party/yyjson/CMakeLists.txt to exist. Reader and writer
support stay enabled; yyjson tests, fuzzer, misc tools, docs, install targets,
JSON5/non-standard support, utilities and incremental reader support are disabled
for the mars-nwe build.
Planned: wolfSSL
wolfSSL is the planned fixed TLS implementation for mars-nwe. It should be
added as third_party/wolfssl and configured by CMake for the server's supported
platforms and enabled TLS features.
mars-nwe code should not include wolfSSL headers directly from arbitrary
subsystems. TLS users should go through the future include/nwtls.h facade and
its wolfSSL backend, for example:
include/nwtls.h
src/nwtls.c
src/nwtls_wolfssl.c
Planned uses include LDAP/LDAPS/StartTLS in nwdirectory and any future
TCP-based internal provider IPC that requires mTLS.
Planned: libflaim
libflaim is the planned bundled persistent storage engine for the future
libdirectory store. It belongs under third_party/libflaim because it is a
storage engine dependency, not a mars-nwe service fork.
The import should be mars-nwe-maintained. The initial source may come from the
SourceForge FLAIM code base or from a distro-vetted source package such as the
openSUSE libflaim-4.9.1046 source package. The exact source, version, distro
patches, licenses, and local changes must be documented in
third_party/libflaim/README.mars-nwe.md.
The original FLAIM build system should be replaced with a real CMake build, not
wrapped from the mars-nwe build. The resulting tree should build both as a
standalone library project and as a mars-nwe subdirectory, exposing a normal CMake
target such as FLAIM::flaim.
FLAIM is C++ code. mars-nwe C components should not include FLAIM C++ headers
directly. Access should go through the future libdirectory C API.
Planned: zlog
zlog is the planned optional advanced logging backend. If added, it should live
under third_party/zlog and be used only through the mars-nwe nwlog facade:
include/nwlog.h
src/nwlog.c
src/nwlog_zlog.c
Endpoint and provider code must not call zlog APIs directly. This keeps secret redaction, request correlation fields, and fallback logging centralized.
Forked components are not third_party
Components that are forked and integrated as mars-nwe services should live at the
repository root, following the existing pattern used by admin, dosutils,
mail, and smart.
The planned tinyldap fork is such a component. It should live as
mars-tinyldap/ at the repository root. Its standalone identity remains
tinyldap, while the mars-nwe integration builds the project-facing
nwdirectory service. The fork should gain a real CMake build that works both
standalone under the tinyldap name and as a mars-nwe subdirectory, and it should
later use libdirectory/libflaim-backed storage instead of tinyldap's original
flat-file storage.