2019-02-13 20:58:38 -06:00
# `cbindgen`   [![Build Status]][travis] [![Latest Version]][crates.io] [![Api Rustdoc]][rustdoc] [](https://github.com/eqrion/cbindgen)
2017-04-27 17:41:01 -04:00
2017-08-12 04:17:34 -04:00
[Build Status]: https://api.travis-ci.org/eqrion/cbindgen.svg?branch=master
2017-08-01 03:56:02 -04:00
[travis]: https://travis-ci.org/eqrion/cbindgen
2017-04-27 17:41:01 -04:00
[Latest Version]: https://img.shields.io/crates/v/cbindgen.svg
[crates.io]: https://crates.io/crates/cbindgen
2017-09-29 15:49:56 -04:00
[Api Rustdoc]: https://img.shields.io/badge/api-rustdoc-blue.svg
2018-05-15 14:17:45 -07:00
[rustdoc]: https://docs.rs/cbindgen
2017-04-05 18:14:21 -04:00
2017-05-08 01:26:44 -04:00
This project can be used to generate C bindings for Rust code. It is currently being developed to support creating bindings for [WebRender ](https://github.com/servo/webrender/ ), but has been designed to support any project.
2017-04-11 18:26:14 -04:00
2017-04-17 21:39:40 -04:00
## Features
* Builds bindings for a crate, its mods, its dependent crates, and their mods
* Only the necessary types for exposed functions are given bindings
2017-05-11 03:57:57 -04:00
* Can specify annotations for controlling some aspects of binding
2017-10-19 00:43:51 -04:00
* Support for generic structs and unions
* Support for exporting constants and statics
2017-05-08 01:26:44 -04:00
* Customizable formatting, can be used in C or C++ projects
2017-08-17 20:14:34 -04:00
* Support for generating `#ifdef` 's for `#[cfg]` attributes
2018-01-29 11:49:57 -06:00
* Support for `#[repr(sized)]` tagged enum's
2017-04-17 21:39:40 -04:00
2019-03-24 20:56:17 +01:00
## Installation
2018-09-12 18:03:41 +05:30
```
cargo install cbindgen
```
or
```
2018-10-16 16:04:00 -05:00
# This will update cbindgen if it's already installed
2018-09-12 18:03:41 +05:30
cargo install --force cbindgen
```
2017-04-12 11:42:43 -04:00
## Use
2017-04-05 18:28:30 -04:00
2017-04-17 22:26:18 -04:00
### Command line
2018-04-15 22:55:10 -04:00
```
cbindgen crate/ -o crate/bindings.h
```
2017-04-12 11:42:43 -04:00
2017-04-17 22:26:18 -04:00
See `cbindgen --help` for more options.
### `build.rs`
`cbindgen` can also be used in build scripts. How this fits into compiling the native code depends on your project.
Here's an example build.rs script:
```rust
extern crate cbindgen;
2017-04-30 01:52:44 -04:00
use std::env;
2017-04-17 22:26:18 -04:00
fn main() {
2017-06-21 03:33:45 -04:00
let crate_dir = env::var("CARGO_MANIFEST_DIR").unwrap();
2017-11-14 22:06:46 -05:00
cbindgen::Builder::new()
.with_crate(crate_dir)
.generate()
.expect("Unable to generate bindings")
2017-06-21 03:33:45 -04:00
.write_to_file("bindings.h");
2017-04-17 22:26:18 -04:00
}
2017-04-18 03:14:55 -04:00
2017-04-17 22:26:18 -04:00
```
2018-10-16 16:04:00 -05:00
You can add configuration options using the [`Builder` ](https://docs.rs/cbindgen/*/cbindgen/struct.Builder.html#methods ) interface.
If you'd like to use a `build.rs` script with a `cbindgen.toml` , consider using [`cbindgen::generate()` ](https://docs.rs/cbindgen/*/cbindgen/fn.generate.html ) instead.
2017-06-21 04:39:02 -04:00
## Configuration
2017-11-14 22:06:46 -05:00
There are some options that can be used to configure the binding generation.
For the command line, they can be specified by creating a `cbindgen.toml` with the options. This can be placed in the binding crate root or at a path manually specified.
2017-11-14 22:50:43 -05:00
For build scripts, options can be specified on the builder or by writing a `cbindgen.toml` and using the helper function `cbindgen::generate` .
2017-06-29 00:12:09 -04:00
Here is a description of the options available in a config.
```toml
# An optional string of text to output at the beginning of the generated file
2017-06-29 00:25:56 -04:00
header = "/* Text to put at the beginning of the generated file. Probably a license. */"
2017-06-29 00:12:09 -04:00
# An optional string of text to output at the end of the generated file
2017-06-29 00:25:56 -04:00
trailer = "/* Text to put at the end of the generated file */"
2017-06-29 00:12:09 -04:00
# An optional name to use as an include guard
2017-06-29 00:25:56 -04:00
include_guard = "mozilla_wr_bindings_h"
2017-06-29 00:12:09 -04:00
# An optional string of text to output between major sections of the generated
# file as a warning against manual editing
2017-06-29 00:29:18 -04:00
autogen_warning = "/* Warning, this file is autogenerated by cbindgen. Don't modify this manually. */"
2017-06-29 00:12:09 -04:00
# Whether to include a comment with the version of cbindgen used to generate the
# file
2017-06-29 00:25:56 -04:00
include_version = true
2017-06-29 00:12:09 -04:00
# An optional namespace to output around the generated bindings
2017-06-29 00:25:56 -04:00
namespace = "ffi"
2017-06-29 00:12:09 -04:00
# An optional list of namespaces to output around the generated bindings
2017-06-29 00:25:56 -04:00
namespaces = ["mozilla", "wr"]
2017-06-29 00:12:09 -04:00
# The style to use for curly braces
2017-06-29 00:25:56 -04:00
braces = "[SameLine|NextLine]"
2017-06-29 00:12:09 -04:00
# The desired length of a line to use when formatting lines
2017-06-29 00:25:56 -04:00
line_length = 80
2017-06-29 00:12:09 -04:00
# The amount of spaces in a tab
2017-06-29 00:25:56 -04:00
tab_width = 2
2017-06-29 00:12:09 -04:00
# The language to output bindings in
2017-06-29 00:25:56 -04:00
language = "[C|C++]"
2018-03-15 16:29:25 +01:00
# A rule to use to select style of declaration in C, tagname vs typedef
style = "[Both|Type|Tag]"
2019-03-24 20:56:17 +01:00
# How the generated documentation should be commented.
# C uses /* */; C++ uses //; Doxy is like C but with leading * per line.
documentation_style = "[C, C++, Doxy]"
2017-06-29 00:12:09 -04:00
2018-08-08 20:44:02 +02:00
[defines]
# A rule for generating `#ifdef`s for matching `#[cfg]`ed items,
# e.g. `#[cfg(foo = "bar")] ...` -> `#if defined(FOO_IS_BAR) ... #endif`
"foo = bar" = "FOO_IS_BAR"
2017-06-29 00:12:09 -04:00
[parse]
# Whether to parse dependent crates and include their types in the generated
# bindings
2017-06-29 00:25:56 -04:00
parse_deps = true
2017-06-29 00:12:09 -04:00
# A white list of crate names that are allowed to be parsed
2017-06-29 00:25:56 -04:00
include = ["webrender", "webrender_traits"]
2017-06-29 00:12:09 -04:00
# A black list of crate names that are not allowed to be parsed
2017-06-29 00:25:56 -04:00
exclude = ["libc"]
2018-04-04 20:48:03 +02:00
# Whether to use a new temporary target directory when running `rustc --pretty=expanded`.
# This may be required for some build processes.
clean = false
2017-06-29 00:12:09 -04:00
Add ability to specify features to use for macro expansion
Currently, `cbindgen` uses the `--all-features` flag when expanding a
dependent crate. However, this may not be desirable in a number of
cases:
- Some C APIs may be gated by a feature flag and would not be present
in the final cdylib depending on the features provided (for instance
one could want to have the ability to build a "debug" version of the
library which provides extra unstable hooks). In such cases, a
programmatic `cbindgen` call in a build script would want to use only
the features that will get used in the current build.
- Some features may bring in large dependencies and/or potentially
increase compilation time without affecting the FFI surface, and it
would be faster and more efficient to disable them when running
`cbindgen`.
- Some features may require external libraries and/or hardware (e.g.
dependencies on GPU libraries such as CUDA) that may not be available
on the current machine without affecting the FFI surface.
To alleviate this problem, this PR adds an extended version of the
`parse.expand` configuration key, allowing control over the features
used when expanding in a way similar to the way cargo handles extended
dependencies (although note that there is a single version of each key,
since the features refer to the features of the current crate). So for
instance instead of writing `expand = ["euclid"]` one would write:
```
[parse.expand]
crates = ["euclid"]
```
which is equivalent to:
```
[parse.expand]
crates = ["euclid"]
all_features = false
default_features = true
features = ["feature1", "feature2"]
```
Note that `all_features` is set to `false` by default in order to match
cargo's behavior.
For backwards compatibility, the old syntax `expand = ["euclid"]` is
still supported and is equivalent to:
```
[parse.expand]
crates = ["euclid"]
all_features = true
default_features = true
features = null
```
In this case, `all_features` is set to `true` in order to match the
previous behavior of cbindgen.
2018-07-27 17:05:31 +02:00
[parse.expand]
# A list of crate names that should be run through `cargo expand` before
# parsing to expand any macros
crates = ["euclid"]
# If enabled, use the `--all-features` option when expanding. Ignored when
2018-07-31 13:17:43 +02:00
# `features` is set. Disabled by default, except when using the
Add ability to specify features to use for macro expansion
Currently, `cbindgen` uses the `--all-features` flag when expanding a
dependent crate. However, this may not be desirable in a number of
cases:
- Some C APIs may be gated by a feature flag and would not be present
in the final cdylib depending on the features provided (for instance
one could want to have the ability to build a "debug" version of the
library which provides extra unstable hooks). In such cases, a
programmatic `cbindgen` call in a build script would want to use only
the features that will get used in the current build.
- Some features may bring in large dependencies and/or potentially
increase compilation time without affecting the FFI surface, and it
would be faster and more efficient to disable them when running
`cbindgen`.
- Some features may require external libraries and/or hardware (e.g.
dependencies on GPU libraries such as CUDA) that may not be available
on the current machine without affecting the FFI surface.
To alleviate this problem, this PR adds an extended version of the
`parse.expand` configuration key, allowing control over the features
used when expanding in a way similar to the way cargo handles extended
dependencies (although note that there is a single version of each key,
since the features refer to the features of the current crate). So for
instance instead of writing `expand = ["euclid"]` one would write:
```
[parse.expand]
crates = ["euclid"]
```
which is equivalent to:
```
[parse.expand]
crates = ["euclid"]
all_features = false
default_features = true
features = ["feature1", "feature2"]
```
Note that `all_features` is set to `false` by default in order to match
cargo's behavior.
For backwards compatibility, the old syntax `expand = ["euclid"]` is
still supported and is equivalent to:
```
[parse.expand]
crates = ["euclid"]
all_features = true
default_features = true
features = null
```
In this case, `all_features` is set to `true` in order to match the
previous behavior of cbindgen.
2018-07-27 17:05:31 +02:00
# `expand = ["euclid"]` shorthand for backwards-compatibility.
all_features = false
2018-07-31 13:17:43 +02:00
# When `all_features` is disabled and this is also disabled, use the
Add ability to specify features to use for macro expansion
Currently, `cbindgen` uses the `--all-features` flag when expanding a
dependent crate. However, this may not be desirable in a number of
cases:
- Some C APIs may be gated by a feature flag and would not be present
in the final cdylib depending on the features provided (for instance
one could want to have the ability to build a "debug" version of the
library which provides extra unstable hooks). In such cases, a
programmatic `cbindgen` call in a build script would want to use only
the features that will get used in the current build.
- Some features may bring in large dependencies and/or potentially
increase compilation time without affecting the FFI surface, and it
would be faster and more efficient to disable them when running
`cbindgen`.
- Some features may require external libraries and/or hardware (e.g.
dependencies on GPU libraries such as CUDA) that may not be available
on the current machine without affecting the FFI surface.
To alleviate this problem, this PR adds an extended version of the
`parse.expand` configuration key, allowing control over the features
used when expanding in a way similar to the way cargo handles extended
dependencies (although note that there is a single version of each key,
since the features refer to the features of the current crate). So for
instance instead of writing `expand = ["euclid"]` one would write:
```
[parse.expand]
crates = ["euclid"]
```
which is equivalent to:
```
[parse.expand]
crates = ["euclid"]
all_features = false
default_features = true
features = ["feature1", "feature2"]
```
Note that `all_features` is set to `false` by default in order to match
cargo's behavior.
For backwards compatibility, the old syntax `expand = ["euclid"]` is
still supported and is equivalent to:
```
[parse.expand]
crates = ["euclid"]
all_features = true
default_features = true
features = null
```
In this case, `all_features` is set to `true` in order to match the
previous behavior of cbindgen.
2018-07-27 17:05:31 +02:00
# `--no-default-features` option when expanding. Enabled by default.
default_features = true
# A list of feature names that should be used when running `cargo expand`. This
# combines with `default_features` like in `Cargo.toml`. Note that the features
# listed here are features for the current crate being built, *not* the crates
# being expanded. The crate's `Cargo.toml` must take care of enabling the
# appropriate features in its dependencies
features = ["cbindgen"]
2018-01-04 23:29:21 -06:00
[export]
# A list of additional items not used by exported functions to include in
# the generated bindings
include = ["Foo", "Bar"]
# A list of items to not include in the generated bindings
exclude = ["Bad"]
# A prefix to add before the name of every item
prefix = "CAPI_"
2018-07-25 12:56:24 +02:00
# Types of items that we'll generate.
item_types = ["constants", "globals", "enums", "structs", "unions", "typedefs", "opaque", "functions"]
2018-01-04 23:29:21 -06:00
# Table of name conversions to apply to item names
[export.rename]
"Struct" = "CAPI_Struct"
2019-01-18 22:57:36 +01:00
# Table of stuff to add to an item body.
[export.body]
"Struct" = """
void cppMethod() const;
"""
2017-06-29 00:12:09 -04:00
[fn]
# An optional prefix to put before every function declaration
2017-06-29 00:25:56 -04:00
prefix = "string"
2017-06-29 00:12:09 -04:00
# An optional postfix to put after any function declaration
2017-06-29 00:25:56 -04:00
postfix = "string"
2017-06-29 00:12:09 -04:00
# How to format function arguments
2017-06-29 00:38:53 -04:00
args = "[Auto|Vertical|Horizontal]"
2017-06-29 00:12:09 -04:00
# A rule to use to rename function argument names
2017-06-29 00:37:38 -04:00
rename_args = "[None|GeckoCase|LowerCase|UpperCase|PascalCase|CamelCase|SnakeCase|ScreamingSnakeCase|QualifiedScreamingSnakeCase]"
2017-06-29 00:12:09 -04:00
[struct]
# A rule to use to rename field names
2017-06-29 00:37:38 -04:00
rename_fields = "[None|GeckoCase|LowerCase|UpperCase|PascalCase|CamelCase|SnakeCase|ScreamingSnakeCase|QualifiedScreamingSnakeCase]"
2017-06-29 00:12:09 -04:00
# Whether to derive an operator== for all structs
2017-06-29 00:25:56 -04:00
derive_eq = false
2017-06-29 00:12:09 -04:00
# Whether to derive an operator!= for all structs
2017-06-29 00:25:56 -04:00
derive_neq = false
2017-06-29 00:12:09 -04:00
# Whether to derive an operator< for all structs
2017-06-29 00:25:56 -04:00
derive_lt = false
2017-06-29 00:12:09 -04:00
# Whether to derive an operator<= for all structs
2017-06-29 00:25:56 -04:00
derive_lte = false
2017-06-29 00:12:09 -04:00
# Whether to derive an operator> for all structs
2017-06-29 00:25:56 -04:00
derive_gt = false
2017-06-29 00:12:09 -04:00
# Whether to derive an operator>= for all structs
2017-06-29 00:25:56 -04:00
derive_gte = false
2017-06-29 00:12:09 -04:00
[enum]
# A rule to use to rename enum variants
2017-06-29 00:37:38 -04:00
rename_variants = "[None|GeckoCase|LowerCase|UpperCase|PascalCase|CamelCase|SnakeCase|ScreamingSnakeCase|QualifiedScreamingSnakeCase]"
2017-06-29 00:25:56 -04:00
2017-06-29 00:12:09 -04:00
```
2017-06-21 04:39:02 -04:00
2017-04-17 21:39:40 -04:00
## Examples
2017-11-14 21:28:30 -05:00
See `tests/rust/` for some examples of rust source that can be handled.
2017-04-17 21:39:40 -04:00
2017-09-29 16:02:55 -04:00
## Major differences between `cbindgen` and `rusty-cheddar`
1. `cbindgen` supports generics
2. `cbindgen` supports C++ output using `enum class` and `template specialization`
3. `cbindgen` supports generating bindings including multiple modules and crates
There may be other differences, but those are the ones that I know of. Please correct me if I misrepresented anything.
2017-11-14 17:43:18 -05:00
## Prominent users
2017-11-14 21:28:30 -05:00
2017-11-14 17:43:18 -05:00
* [milksnake ](https://github.com/getsentry/milksnake )
* [webrender ](https://searchfox.org/mozilla-central/source/gfx/webrender_bindings/webrender_ffi_generated.h )
2018-11-08 10:51:59 -05:00
* [wgpu ](https://github.com/gfx-rs/wgpu/blob/master/wgpu-bindings/wgpu.h )
2017-11-14 21:28:30 -05:00
If you're using `cbindgen` and would like to be added to this list, please open a pull request!