Skip to content

Build against Memgraph 3.1 headers and meson 1.3 - #1

Closed
vkatter-uantwerpen wants to merge 2 commits into
gaperez64:mainfrom
vkatter-uantwerpen:memgraph-3.1-compat
Closed

Build against Memgraph 3.1 headers and meson 1.3#1
vkatter-uantwerpen wants to merge 2 commits into
gaperez64:mainfrom
vkatter-uantwerpen:memgraph-3.1-compat

Conversation

@vkatter-uantwerpen

Copy link
Copy Markdown

A clean checkout does not build against a stock Memgraph 3.1 install. Two
independent reasons, one commit each.

1. meson stops before compiling

meson.build sets c_std=c23, but meson only recognises that value from 1.4,
while the project declares meson_version: '>=1.3.0'. On meson 1.3.x:

ERROR: Unknown C std ['c23']. Possible values are [... 'c2x' ...]

c2x selects the same standard and is accepted across the whole declared meson
range, so the first commit just changes the spelling.

2. Three mgp_* functions do not exist in 3.1.1

src/memgraph/sync_module.c calls mgp_list_append_move,
mgp_map_insert_move and mgp_unordered_map_make_empty. None are declared in
mg_procedure.h on Memgraph 3.1.1, so the module fails to compile.

The second commit adds guarded shims built on the copying variants
(mgp_list_append, mgp_map_insert, mgp_map_make_empty), and has meson
detect the situation with cc.has_header_symbol instead of requiring
-DSYNC_KGRAPH_MGP_COMPAT to be passed by hand:

Header "mg_procedure.h" has symbol "mgp_list_append_move" : NO
Message: Memgraph headers predate mgp_*_move; enabling compat shims.

Against newer headers the symbol is found, the shims compile out entirely, and
nothing changes.

One thing worth your review

mgp_list_append and mgp_map_insert copy the value, so the shims destroy the
source on success in order to preserve the move-semantics contract the call
sites rely on (they already destroy the value themselves on failure). I believe
that matches what the real *_move functions do, but it is my inference about
the intended contract rather than something the headers state — and if it is
wrong it is a leak or a double free rather than a compile error. You wrote the
call sites, so you are better placed to confirm it than I am.

Nothing currently exercises it either: the shims are only reachable on older
Memgraph headers, and the test suite covers src/sync.c rather than the module.

Verified

Fresh clone of this branch, Memgraph 3.1.1 headers, meson 1.3.2, clang 18:

CC=clang meson setup build -Dmemgraph=enabled -Dmemgraph_include_dir=/usr/include/memgraph
ninja -C build

Builds sync.so with no hand-passed flags, and meson test -C build passes.

Vincent added 2 commits August 17, 2026 13:15
meson only added 'c23' as a recognised c_std value in 1.4, but the project
declares meson_version >=1.3.0. On meson 1.3.x configuration fails outright:

    ERROR: Unknown C std ['c23']. Possible values are [... 'c2x' ...]

Newer meson still accepts 'c2x' and it selects the same standard, so 'c2x' is
the spelling that works across the supported meson range.
sync_module.c calls mgp_list_append_move, mgp_map_insert_move and
mgp_unordered_map_make_empty. Memgraph 3.1.1 ships none of them, so the module
fails to compile against a stock 3.1 install.

Add guarded shims implementing the three on top of the copying variants, and
detect the situation in meson via cc.has_header_symbol rather than requiring
-DSYNC_KGRAPH_MGP_COMPAT to be passed by hand. Against newer headers the shims
compile out entirely and nothing changes.

Note for review: mgp_list_append and mgp_map_insert copy the value, so the shims
destroy the source on success to preserve the move-semantics contract the call
sites rely on (they destroy the value themselves on failure). That mirrors what
the real *_move functions do, but it is an assumption about the intended
contract rather than something the headers state, so it is worth confirming.
@gaperez64

Copy link
Copy Markdown
Owner

#2 supersedes this and carries the same commits + the syntax-check failures fixed @vkatter-uantwerpen

@gaperez64 gaperez64 closed this Aug 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants