1# Contributing to `libc` 2 3Welcome! If you are reading this document, it means you are interested in 4contributing to the `libc` crate. 5 6## v0.2 changes 7 8If you want to add your changes to v0.2, please submit them to the `libc-0.2` 9branch. If you want to add any breaking changes, it should be submitted to the 10main branch, which has changes for v0.3. We will support and make a new release 11for v0.2 until we make the first release of v0.3. 12 13## Adding an API 14 15Want to use an API which currently isn't bound in `libc`? It's quite easy to add 16one! 17 18The internal structure of this crate is designed to minimize the number of 19`#[cfg]` attributes in order to easily be able to add new items which apply to 20all platforms in the future. As a result, the crate is organized hierarchically 21based on platform. Each module has a number of `#[cfg]`'d children, but only one 22is ever actually compiled. Each module then reexports all the contents of its 23children. 24 25This means that for each platform that libc supports, the path from a leaf 26module to the root will contain all bindings for the platform in question. 27Consequently, this indicates where an API should be added! Adding an API at a 28particular level in the hierarchy means that it is supported on all the child 29platforms of that level. For example, when adding a Unix API it should be added 30to `src/unix/mod.rs`, but when adding a Linux-only API it should be added to 31`src/unix/linux_like/linux/mod.rs`. 32 33If you're not 100% sure at what level of the hierarchy an API should be added 34at, fear not! This crate has CI support which tests any binding against all 35platforms supported, so you'll see failures if an API is added at the wrong 36level or has different signatures across platforms. 37 38New symbol(s) (i.e. functions, constants etc.) should also be added to the 39symbols list(s) found in the `libc-test/semver` directory. These lists keep 40track of what symbols are public in the libc crate and ensures they remain 41available between changes to the crate. If the new symbol(s) are available on 42all supported Unixes it should be added to `unix.txt` list<sup>1</sup>, 43otherwise they should be added to the OS specific list(s). 44 45With that in mind, the steps for adding a new API are: 46 471. Determine where in the module hierarchy your API should be added. 482. Add the API, including adding new symbol(s) to the semver lists. 493. Send a PR to this repo. 504. Wait for CI to pass, fixing errors. 515. Wait for a merge! 52 53<sup>1</sup>: Note that this list has nothing to do with any Unix or Posix 54standard, it's just a list shared between all OSs that declare `#[cfg(unix)]`. 55 56## Test before you commit 57 58We have two automated tests running on 59[GitHub Actions](https://github.com/rust-lang/libc/actions): 60 611. [`libc-test`](https://github.com/gnzlbg/ctest) 62 - `cd libc-test && cargo test` 63 - Use the `skip_*()` functions in `build.rs` if you really need a workaround. 642. Style checker 65 - [`sh ci/style.sh`](https://github.com/rust-lang/libc/blob/main/ci/style.sh) 66 67## Breaking change policy 68 69Sometimes an upstream adds a breaking change to their API e.g. removing outdated 70items, changing the type signature, etc. And we probably should follow that 71change to build the `libc` crate successfully. It's annoying to do the 72equivalent of semver-major versioning for each such change. Instead, we mark the 73item as deprecated and do the actual change after a certain period. The steps 74are: 75 761. Add `#[deprecated(since = "", note="")]` attribute to the item. 77 - The `since` field should have a next version of `libc` (e.g., if the current 78 version is `0.2.1`, it should be `0.2.2`). 79 - The `note` field should have a reason to deprecate and a tracking issue to 80 call for comments (e.g., "We consider removing this as the upstream removed 81 it. If you're using it, please comment on #XXX"). 82 832. If we don't see any concerns for a while, do the change actually. 84 85## Supported target policy 86 87When Rust removes a support for a target, the libc crate also may remove the 88support anytime. 89 90## Releasing your change to crates.io 91 92This repository uses [release-plz] to handle releases. Once your pull request 93has been merged, a maintainer just needs to verify the generated changelog, then 94merge the bot's release PR. This will automatically publish to crates.io! 95 96[release-plz]: https://github.com/MarcoIeni/release-plz 97