@@ -9,11 +9,11 @@ around build commands to facilitate linking native code to Cargo packages.
9
9
10
10
1 . Instead of having the ` build ` command be some form of script, it will be a
11
11
Rust command instead
12
- 2 . Establish a namespace of ` foo_sys ` packages which represent the native
12
+ 2 . Establish a namespace of ` foo-sys ` packages which represent the native
13
13
library ` foo ` . These packages will have Cargo-based dependencies between
14
- ` *_sys ` packages to express dependencies among C packages themselves.
14
+ ` *-sys ` packages to express dependencies among C packages themselves.
15
15
3 . Establish a set of standard environment variables for build commands which
16
- will instruct how ` foo_sys ` packages should be built in terms of dynamic or
16
+ will instruct how ` foo-sys ` packages should be built in terms of dynamic or
17
17
static linkage, as well as providing the ability to override where a package
18
18
comes from via environment variables.
19
19
@@ -101,7 +101,7 @@ Summary:
101
101
* Add platform-specific dependencies to Cargo manifests
102
102
* Allow pre-built libraries in the same manner as Cargo overrides
103
103
* Use Rust for build scripts
104
- * Develop a convention of ` *_sys ` packages
104
+ * Develop a convention of ` *-sys ` packages
105
105
106
106
## Modifications to ` rustc `
107
107
@@ -358,38 +358,38 @@ useful to interdependencies among native packages themselves. For example
358
358
libssh2 depends on OpenSSL on linux, which means it needs to find the
359
359
corresponding libraries and header files. The metadata keys serve as a vector
360
360
through which this information can be transmitted. The maintainer of the
361
- ` openssl_sys ` package (described below) would have a build script responsible
361
+ ` openssl-sys ` package (described below) would have a build script responsible
362
362
for generating this sort of metadata so consumer packages can use it to build C
363
363
libraries themselves.
364
364
365
- ## A set of ` *_sys ` packages
365
+ ## A set of ` *-sys ` packages
366
366
367
367
This section will discuss a * convention* by which Cargo packages providing
368
368
native dependencies will be named, it is not proposed to have Cargo enforce this
369
369
convention via any means. These conventions are proposed to address constraints
370
370
5 and 6 above.
371
371
372
- Common C dependencies will be refactored into a package named ` foo_sys ` where
373
- ` foo ` is the name of the C library that ` foo_sys ` will provide and link to.
372
+ Common C dependencies will be refactored into a package named ` foo-sys ` where
373
+ ` foo ` is the name of the C library that ` foo-sys ` will provide and link to.
374
374
There are two key motivations behind this convention:
375
375
376
- * Each ` foo_sys ` package will declare its own dependencies on other ` foo_sys `
376
+ * Each ` foo-sys ` package will declare its own dependencies on other ` foo-sys `
377
377
based packages
378
378
* Dependencies on native libraries expressed through Cargo will be subject to
379
379
version management, version locking, and deduplication as usual.
380
380
381
- Each ` foo_sys ` package is responsible for providing the following:
381
+ Each ` foo-sys ` package is responsible for providing the following:
382
382
383
- * Declarations of all symbols in a library. Essentially each ` foo_sys ` library
383
+ * Declarations of all symbols in a library. Essentially each ` foo-sys ` library
384
384
is * only* a header file in terms of Rust-related code.
385
- * Ensuring that the native library ` foo ` is linked to the ` foo_sys ` crate. This
385
+ * Ensuring that the native library ` foo ` is linked to the ` foo-sys ` crate. This
386
386
guarantees that all exposed symbols are indeed linked into the crate.
387
387
388
- Dependencies making use of ` *_sys ` packages will not expose ` extern ` blocks
389
- themselves, but rather use the symbols exposed in the ` foo_sys ` package
390
- directly. Additionally, packages using ` *_sys ` packages should not declare a
388
+ Dependencies making use of ` *-sys ` packages will not expose ` extern ` blocks
389
+ themselves, but rather use the symbols exposed in the ` foo-sys ` package
390
+ directly. Additionally, packages using ` *-sys ` packages should not declare a
391
391
` #[link] ` directive to link to the native library as it's already linked to the
392
- ` *_sys ` package.
392
+ ` *-sys ` package.
393
393
394
394
## Phasing strategy
395
395
@@ -517,7 +517,7 @@ perform this configuration (be it environment or in files).
517
517
* Features themselves will also likely need to be platform-specific, but this
518
518
runs into a number of tricky situations and needs to be fleshed out.
519
519
520
- [ verbose ] : https://github.com/alexcrichton/complicated-linkage-example/blob/master/curl_sys /Cargo.toml#L9-L17
520
+ [ verbose ] : https://github.com/alexcrichton/complicated-linkage-example/blob/master/curl-sys /Cargo.toml#L9-L17
521
521
522
522
# Alternatives
523
523
0 commit comments