Installation¶

melon is header-only and dependency-free: adding its include/ directory to your include path and compiling with C++23 is enough. The sections below cover the packaged routes, which additionally give you an imported CMake target.

Requirements¶

C++23 is the baseline; GCC 15 / C++26 is recommended. Every configuration below is exercised by CI on every commit.

The compiler floors are really standard-library floors: libstdc++ 14 or libc++ 20, whichever the compiler is paired with. Clang against an older libstdc++ stops at a single readable #error naming the requirement. On libc++ the limiting feature is std::jthread, which is experimental before release 20; Apple Clang 21 (Xcode 26.4) is the first Apple toolchain whose libc++ meets it, and the Apple Clang 17 line (Xcode 16.3 to 26.3) does not. Linux and Windows clang builds against libc++ 20 or newer are expected to work but are not in the CI matrix.

CMake 3.24 or later is required for the CMake integration, and Conan 2.0 or later for the Conan one. Asking CMake for a C++26 build needs 3.30: CXX_STANDARD 26 became a valid value in 3.25, but no -std=c++26 mapping exists for GCC before 3.30, where the cxx_std_26 compile feature was finally implemented. Older CMake is not an error — the melon::melon target requires only cxx_std_23, so you get a working C++23 build with the range shapes noted below.

As a Conan package¶

From the repository (the tagged 1.0.0 release — the recommended route):

$ git clone https://github.com/fhamonic/melon
$ cd melon
$ conan create . -u -b=missing -pr=<your_conan_profile>

Then declare the dependency in your own conanfile.txt:

[requires]
melon/1.0.0

[generators]
CMakeDeps
CMakeToolchain

From Conan Center (latest published release):

[requires]
melon/1.0.0-alpha.1

Either way, consume it from CMake with:

find_package(melon CONFIG REQUIRED)
target_link_libraries(<your_target> PRIVATE melon::melon)

As a CMake subdirectory¶

Clone melon into your project, or add it as a submodule:

$ git submodule add https://github.com/fhamonic/melon dependencies/melon

then:

add_subdirectory(dependencies/melon)
target_link_libraries(<your_target> PRIVATE melon::melon)

The melon target is an INTERFACE library carrying the cxx_std_23 compile feature, so linking against it raises your target's standard if needed. It exports no warning flags of its own.

MELON_BUILD_TESTS defaults to PROJECT_IS_TOP_LEVEL, so consuming melon this way builds no tests and downloads no GTest.

Installed system-wide¶

$ cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DMELON_BUILD_TESTS=OFF
$ cmake --install build --prefix /usr/local

This installs the headers together with melonConfig.cmake and melonConfigVersion.cmake (SameMajorVersion, architecture-independent), so consumers can find_package(melon CONFIG) exactly as with the Conan package.

Headers¶

Every component is a separate header under melon/, and you include what you use:

#include "melon/container/static_digraph.hpp"
#include "melon/algorithm/dijkstra.hpp"

melon/all.hpp pulls in the entire public API — convenient for a scratch program, wasteful in a build you care about. The header map lists every header and what it declares.

Everything lives in namespace melon. Prior releases nested it inside an umbrella fhamonic namespace; that was removed, so fhamonic::melon::dijkstra is now melon::dijkstra.

Four sub-namespaces carve out the parts that would otherwise take very generic names at top level: melon::views for graph views, melon::maps for mapping views, melon::numeric for rational / integer / bounded_value, and melon::experimental. See Headers.

API stability¶

Starting with 1.0.0, melon follows semantic versioning: every header is frozen API for the whole 1.x series, with two explicit exceptions that carry no stability guarantee and may change or disappear in any release:

• melon/detail/ — implementation details, as well as any symbol in a detail namespace;
• melon/experimental/ — work-in-progress data structures. These live in namespace melon::experimental, so nothing reaches the stable melon namespace by accident.

The guarantee covers every documented name in namespace melon, melon::views, melon::maps and melon::numeric — the customization point objects (vertices, out_arcs, …) are reachable as melon:: names and covered as such, while melon::cpo, which holds only their implementation types, stays out per the detail rule above — plus the behavioural contracts stated throughout this documentation — the algorithm lifecycle, the ownership rules, the mapping concepts. Those contracts are deliberate design decisions, each pinned by tests (test/api_consistency.cpp, test/api_review.cpp), and will not be relitigated within 1.x. If a 1.x release ever breaks code that follows them, that is a bug in melon.

melon/version.hpp is the single source of truth for the version number and lets you feature-test:

#include "melon/version.hpp"

#if MELON_VERSION >= 10000  // MAJOR * 10000 + MINOR * 100 + PATCH
    ...
#endif

Building the test suite¶

From a checkout, with Conan:

$ conan build . -b=missing -pr=<your_conan_profile>

or with plain CMake, which falls back to fetching GTest if it is not installed:

$ cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
$ cmake --build build -j"$(nproc)"
$ ctest --test-dir build --output-on-failure

Set MELON_SANITIZE to build the suite with sanitizers, e.g. -DMELON_SANITIZE=address,undefined.

Next steps¶

A first graph walks through building a graph and running an algorithm on it.