Native integrations should depend on an installed TsFile SDK. Use the installation instructions for the TsFile package and platform you select. Do not add a second TsFile installer, vendor the core library, or automatically download and build a floating branch from an extras module.
The established packaging contract provides a library, development headers, CMake package configuration, and pkg-config metadata beneath an installation prefix. The following references describe the SDK at commit 6f38c703962a:
| Installation family | Development requirements |
|---|---|
| APT | Runtime tsfile and development package tsfile-dev. |
| RPM | Runtime tsfile and development package tsfile-devel. |
| Homebrew | The installed Formula's prefix, including library and headers; development Formula tsfile-dev is keg-only. |
| Windows SDK ZIP | The extracted SDK root containing bin, include, and lib, matching the consumer's architecture and toolchain. |
tsfile-tools supplies the CLI where packaging separates it from the library; it is not a substitute for development headers and link files. Availability and installation commands are owned by the TsFile package distribution. Do not infer support for additional platforms or architectures from this table.
CMake-based integrations should use find_package(TsFile CONFIG REQUIRED) and link their actual targets to TsFile::tsfile. Use CMAKE_PREFIX_PATH to select a non-default SDK installation, or TsFile_DIR for the directory containing TsFileConfig.cmake. Consume the exported include paths and dependencies rather than reconstructing them in a custom FindTsFile.cmake.
For a Homebrew development installation, brew --prefix tsfile-dev identifies the Formula-specific prefix. Do not hard-code /opt/homebrew or /usr/local. On Windows, point the consumer at the extracted SDK root, not just its DLL.
Consumers using pkg-config can query libtsfile; configure PKG_CONFIG_PATH when the installation is outside the normal search path. Runtime library resolution is separate from build-time package discovery and must be documented by the integration.
Choose linkage according to the host and distribution requirements. An installed SDK may be shared or static; an existing binary package must not be assumed to contain both variants. Verify the selected artifact, compiler and runtime ABI, position-independent code requirements, and transitive dependencies as relevant.
If the required SDK variant is unavailable as a package, build and install it into a separate prefix using the upstream instructions, then consume that prefix normally. Do not silently switch to a network source build during configuration.
For shared builds, deployment instructions must account for the runtime library. For static builds, preserve the exported dependency and licensing requirements.
To work with an unpublished core change, the developer builds and installs TsFile into a chosen prefix outside this repository. Extras then uses that same CMake or pkg-config interface. SDK source location and build directories are not part of the integration contract.
Installed headers include a compatibility closure, not only stable public entry points. Consult the public-header definition and document any dependence on implementation-level interfaces.
Each implementation should record the following when it is actually exercised:
Development snapshots must remain labeled as such; do not describe them as RCs or formal releases. Pin immutable versions when reproducibility is needed rather than relying on latest or a moving branch.