# C headers this package reads function signatures out of. One per line: a
# path, then any clang flags that header needs. A relative path is against
# this directory, ${NAME} expands from the environment, and a leading `?`
# means "if it is there" — an optional line with nothing behind it is simply
# not read.
#
# Why this exists. The declare-c lines in raylib.flan were transcribed by
# hand from raylib's documentation, and until now nothing could check that
# any of them matched the real function — BUILT.md records that as trusted
# rather than guaranteed. Point this at raylib's own header and the compiler
# reads the signatures instead: every hand-written line is compared against
# the library's, every defstruct against the header's record, and any raylib
# function the package has not bound becomes available under its own name.
#
# Why it is optional. A build needs libraylib linkable and *not* raylib-devel
# installed, which is a property worth keeping; requiring a header would take
# it from everyone to give the check to whoever has one. So the default build
# is unchanged and this is opt-in, the same shape as ${FLAN_RAYLIB_WEB} in
# `link`.
#
# The version must match the shared library `link` names — 5.5, libraylib.so.550.
# Reading one version's header while linking another's library is exactly the
# silent disagreement this exists to prevent, and `flan import-c` will say so:
# against a 5.1-dev header it reports ten differences that are all real.
#
#   export FLAN_RAYLIB_H=/path/to/raylib-5.5/src/raylib.h
#
# To see what it would do without building anything:
#
#   flan import-c $FLAN_RAYLIB_H vendor/raylib/raylib.flan
#
?${FLAN_RAYLIB_H}
