cbindgen

Overview

cbindgen is a tool for generating C and C++ headers from Rust code that exposes a public C API. It is used when a Rust library needs a stable foreign-function interface for C or C++ consumers, and when keeping handwritten headers in sync with Rust definitions would be error-prone.

In a Linux distribution, the package is typically useful for building Rust projects that publish native headers as part of their build process, or for maintainers who need to regenerate those headers during packaging or downstream integration.

Purpose and typical use cases

Typical uses include:

• generating headers for Rust libraries that are consumed from C or C++;
• keeping exported types and function declarations aligned with the Rust implementation;
• supporting downstream builds that expect generated headers rather than manually maintained ones;
• integrating header generation into build.rs or a similar build step.

Typical users include:

• package maintainers working on Rust-based libraries with a C API;
• developers who need to ship or consume native bindings;
• CI/CD maintainers who want header generation to be reproducible in automated builds;
• build engineers who need to verify that generated interfaces still match the upstream Rust code.

Upstream project

Upstream is the eqrion/cbindgen project on GitHub. Its own documentation describes it as a project for generating C bindings from Rust code, and the upstream README explains that it can emit both C and C++ headers from the same Rust library.

NiceOS maintainers should verify upstream behavior, command-line options, and configuration details against the current documentation before relying on them in packaging rules.

Dist-git repository contents

This dist-git repository contains the packaging metadata needed to build and review the RPM package for NiceOS:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source manifest files and related integrity metadata;
• METADATA/ — repository metadata used by the packaging workflow;
• SBOM/ — software bill of materials material, when present for the package or repository workflow.

The repository is meant to describe how the package is built, not to mirror the entire upstream source tree.

Source storage and integrity policy

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps source integrity metadata in SOURCES/ manifest files.

For maintainers, this means:

• verify that the manifest entries still match the upstream source that is being packaged;
• regenerate or refresh the SOURCES metadata when the upstream source changes;
• review any packaging logic that depends on generated files or checked-in artifacts;
• avoid assuming that the Git repository alone is the complete source archive.

If a package workflow uses generated manifests, auxiliary metadata, or downloaded assets, NiceOS maintainers should confirm that those files are refreshed consistently before publishing an update.

NiceOS maintenance notes

Before updating this package, check the following:

• whether upstream changed the header-generation behavior or configuration format;
• whether any packaging patches still apply cleanly;
• whether the spec file needs updates for new build steps or test commands;
• whether any generated files in SOURCES/, SBOM/, or other metadata directories need regeneration;
• whether the update could change generated header output in downstream consumers;
• whether Rust toolchain or build-environment expectations need to be adjusted.

Risks to consider:

• generated headers may change even when upstream code changes look small;
• build-time behavior may differ between cbindgen used as a standalone program and cbindgen embedded in another build process;
• downstream consumers may depend on output formatting or declaration ordering, so output diffs should be reviewed carefully.

Build and verification checklist

For RPM maintenance, a practical checklist is:

• confirm the spec file still points to the intended upstream source and build inputs;
• verify that SOURCES/ metadata matches the packaged source material;
• rebuild the package in a clean environment;
• inspect generated header output if the package or its consumers rely on it;
• run package tests if they are available in the spec or upstream project;
• check that the installed binaries, man pages, and documentation paths are correct;
• review the build log for warnings or missing dependencies;
• compare the resulting file list against expectations for a packaging-only update.

If the package ships example configuration files or templates, verify that they still match the documented behavior.

References

• Upstream repository
• Upstream README and project documentation

Russian documentation

See README_RU.md for the Russian version of this documentation.

Dist-git repository notes

• Package repository: rpms/cbindgen
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.