Lines Matching refs:crate

11 CXX's integration with Cargo is handled through the [cxx-build] crate.
30 [`cc::Build`] instance (from the usual widely used `cc` crate) on which you can
61 With cxx-build, by default your include paths always start with the crate name.
65 Your crate name is determined by the `name` entry in Cargo.toml.
67 For example if your crate is named `yourcratename` and contains a C++ header
74 A crate can choose a prefix for its headers that is different from the crate
99 have `#include "path/to/header.h"`. However, if your crate is a library, be
102 within the crate is sufficiently namespaced or unique.
128 It works the same as an include of a local header: use the crate name (or their
129 include\_prefix if their crate changed it) followed by the relative path of the
130 header within the crate.
136 Note that cross-crate imports are only made available between **direct
137 dependencies**. You must directly depend on the other crate in order to #include
142 will not be importable from outside of the same crate. See *[the `links`
157 of additional directories from which the current crate, directly dependent
158 crates, and further crates to which this crate's headers are exported (more
162 current build via the `cc` crate's [`Build::include`], but *also* makes the
164 headers from your crate. If the dir were added only using `Build::include`, the
165 downstream crate including your header would need to manually add the same
170 When using `exported_header_dirs`, your crate must also set a `links` key for
173 `links` key, which means the downstream crate's build script might otherwise
178 One of your crate's headers wants to include a system library, such as `#include
198 Your crate wants to rearrange the headers that it exports vs how they're laid
199 out locally inside the crate's source directory.
201 Suppose the crate as published contains a file at `./include/myheader.h` but
230 describe which of your dependencies participate in your crate's C++ public API,
231 as opposed to private use by your crate's implementation.
240 The significance of exported headers is that if downstream code (crate **��**)
241 contains an `#include` of a header from your crate (**ℬ**) and your header
243 dependency **��** becomes available during the downstream crate **��**'s build.
244 Otherwise the downstream crate **��** doesn't know about **��** and wouldn't be
247 When using `exported_header_prefixes`, your crate must also set a `links` key
252 Suppose you have a crate with 5 direct dependencies and the `include_prefix` for
283 manifest key*][links]) of one of your crate's direct dependencies.
286 re-exporting a C++ dependency as part of your crate's public API, except with
291 When using `exported_header_links`, your crate must also set a `links` key for