1# Contributing to `libc` 2 3Welcome! If you are reading this document, it means you are interested in contributing 4to the `libc` crate. 5 6## Adding an API 7 8Want to use an API which currently isn't bound in `libc`? It's quite easy to add 9one! 10 11The internal structure of this crate is designed to minimize the number of 12`#[cfg]` attributes in order to easily be able to add new items which apply 13to all platforms in the future. As a result, the crate is organized 14hierarchically based on platform. Each module has a number of `#[cfg]`'d 15children, but only one is ever actually compiled. Each module then reexports all 16the contents of its children. 17 18This means that for each platform that libc supports, the path from a 19leaf module to the root will contain all bindings for the platform in question. 20Consequently, this indicates where an API should be added! Adding an API at a 21particular level in the hierarchy means that it is supported on all the child 22platforms of that level. For example, when adding a Unix API it should be added 23to `src/unix/mod.rs`, but when adding a Linux-only API it should be added to 24`src/unix/linux_like/linux/mod.rs`. 25 26If you're not 100% sure at what level of the hierarchy an API should be added 27at, fear not! This crate has CI support which tests any binding against all 28platforms supported, so you'll see failures if an API is added at the wrong 29level or has different signatures across platforms. 30 31New symbol(s) (i.e. functions, constants etc.) should also be added to the 32symbols list(s) found in the `libc-test/semver` directory. These lists keep 33track of what symbols are public in the libc crate and ensures they remain 34available between changes to the crate. If the new symbol(s) are available on 35all supported Unixes it should be added to `unix.txt` list<sup>1</sup>, 36otherwise they should be added to the OS specific list(s). 37 38With that in mind, the steps for adding a new API are: 39 401. Determine where in the module hierarchy your API should be added. 412. Add the API, including adding new symbol(s) to the semver lists. 423. Send a PR to this repo. 434. Wait for CI to pass, fixing errors. 445. Wait for a merge! 45 46<sup>1</sup>: Note that this list has nothing to do with any Unix or Posix 47standard, it's just a list shared between all OSs that declare `#[cfg(unix)]`. 48 49## Test before you commit 50 51We have two automated tests running on [GitHub Actions](https://github.com/rust-lang/libc/actions): 52 531. [`libc-test`](https://github.com/gnzlbg/ctest) 54 - `cd libc-test && cargo test` 55 - Use the `skip_*()` functions in `build.rs` if you really need a workaround. 562. Style checker 57 - `rustc ci/style.rs && ./style src` 58 59## Breaking change policy 60 61Sometimes an upstream adds a breaking change to their API e.g. removing outdated items, 62changing the type signature, etc. And we probably should follow that change to build the 63`libc` crate successfully. It's annoying to do the equivalent of semver-major versioning 64for each such change. Instead, we mark the item as deprecated and do the actual change 65after a certain period. The steps are: 66 671. Add `#[deprecated(since = "", note="")]` attribute to the item. 68 - The `since` field should have a next version of `libc` 69 (e.g., if the current version is `0.2.1`, it should be `0.2.2`). 70 - The `note` field should have a reason to deprecate and a tracking issue to call for comments 71 (e.g., "We consider removing this as the upstream removed it. 72 If you're using it, please comment on #XXX"). 732. If we don't see any concerns for a while, do the change actually. 74 75## Releasing your change to crates.io 76 77Now that you've done the amazing job of landing your new API or your new 78platform in this crate, the next step is to get that sweet, sweet usage from 79crates.io! The only next step is to bump the version of libc and then publish 80it. If you'd like to get a release out ASAP you can follow these steps: 81 821. Increment the patch version number in `Cargo.toml` and `libc-test/Cargo.toml`. 831. Send a PR to this repository. It should [look like this][example-pr], but it'd 84 also be nice to fill out the description with a small rationale for the 85 release (any rationale is ok though!) 861. Once merged, the release will be tagged and published by one of the libc crate 87 maintainers. 88 89[example-pr]: https://github.com/rust-lang/libc/pull/2120 90