Skip to content

Latest commit

 

History

History
64 lines (41 loc) · 2.55 KB

File metadata and controls

64 lines (41 loc) · 2.55 KB

Contributing

Thanks for your interest. This document covers the practical steps for contributing to llm_invoke_cpp.

Before You Start

Check the open issues and ROADMAP.md to see what is already planned or in progress. For non-trivial changes, open an issue first so the approach can be agreed on before you invest time in a PR.

Project Status

This project is pre-release / alpha. The public API has not been frozen. See ROADMAP.md for the current stabilization priorities.

Setting Up

git clone <repository url>
cd llm_invoke_cpp

cmake -S . -B build -G Ninja -D CMAKE_BUILD_TYPE=Release
cmake --build build --parallel
ctest --test-dir build --output-on-failure

If you do not need the HTTP gateway demo and want to skip downloading cpp-httplib:

cmake -S . -B build -G Ninja -D CMAKE_BUILD_TYPE=Release -D LLM_INVOKE_CPP_BUILD_MCP_HTTP_DEMO=OFF

The only external dependency fetched automatically is nlohmann/json. Test infrastructure uses doctest, also fetched automatically.

Making Changes

  • The library is header-only under include/. Each subdirectory has its own README.md explaining the layer's responsibilities and public headers.
  • Tests live in tests/. Add or update a test for any behavior change.
  • Examples live in examples/. If you add a new demo, wire it up in CMakeLists.txt and add a brief README.md in the example directory.
  • Keep commits focused. One logical change per commit makes review easier.

Code Style

  • C++17 minimum; C++20 is used in parts of the codebase where it is already in use.
  • Match the style of the file you are editing: naming conventions, include order, brace placement.
  • Default to writing no comments. Only add one when the why is non-obvious.

Tests

All tests use doctest. Run the full suite before submitting:

ctest --test-dir build --output-on-failure

Snapshot tests live in tests/snapshots/. If your change intentionally alters a snapshot, update the snapshot file and explain why in the PR description.

Pull Requests

  • Target the main branch.
  • Include a short description of what changed and why.
  • If your PR touches the MCP layer or schema export, note which hosts or clients you tested against, even informally.
  • CI runs Windows and Linux builds automatically. Both must pass.

Reporting Issues

Use the GitHub issue tracker. For bugs, include the compiler version, OS, and a minimal reproducer. For feature requests, describe the use case, not just the API you want.