Skip to content

Clean up documentation generation #1254

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Feb 13, 2019
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 66 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
# Contributing to `libc`

Welcome! If you are reading this document, it means you are interested in contributing
to the `libc` crate.

## Adding an API

Want to use an API which currently isn't bound in `libc`? It's quite easy to add
one!

The internal structure of this crate is designed to minimize the number of
`#[cfg]` attributes in order to easily be able to add new items which apply
to all platforms in the future. As a result, the crate is organized
hierarchically based on platform. Each module has a number of `#[cfg]`'d
children, but only one is ever actually compiled. Each module then reexports all
the contents of its children.

This means that for each platform that libc supports, the path from a
leaf module to the root will contain all bindings for the platform in question.
Consequently, this indicates where an API should be added! Adding an API at a
particular level in the hierarchy means that it is supported on all the child
platforms of that level. For example, when adding a Unix API it should be added
to `src/unix/mod.rs`, but when adding a Linux-only API it should be added to
`src/unix/notbsd/linux/mod.rs`.

If you're not 100% sure at what level of the hierarchy an API should be added
at, fear not! This crate has CI support which tests any binding against all
platforms supported, so you'll see failures if an API is added at the wrong
level or has different signatures across platforms.

With that in mind, the steps for adding a new API are:

1. Determine where in the module hierarchy your API should be added.
2. Add the API.
3. Send a PR to this repo.
4. Wait for CI to pass, fixing errors.
5. Wait for a merge!

### Test before you commit

We have two automated tests running on [Travis](https://travis-ci.org/rust-lang/libc):

1. [`libc-test`](https://github.com/alexcrichton/ctest)
- `cd libc-test && cargo test`
- Use the `skip_*()` functions in `build.rs` if you really need a workaround.
2. Style checker
- `rustc ci/style.rs && ./style src`

### Releasing your change to crates.io

Now that you've done the amazing job of landing your new API or your new
platform in this crate, the next step is to get that sweet, sweet usage from
crates.io! The only next step is to bump the version of libc and then publish
it. If you'd like to get a release out ASAP you can follow these steps:

1. Update the version number in `Cargo.toml`, you'll just be bumping the patch
version number.
2. Run `cargo update` to regenerate the lockfile to encode your version bump in
the lock file. You may pull in some other updated dependencies, that's ok.
3. Send a PR to this repository. It should [look like this][example], but it'd
also be nice to fill out the description with a small rationale for the
release (any rationale is ok though!)
4. Once merged the release will be tagged and published by one of the libc crate
maintainers.

[example]: https://github.com/rust-lang/libc/pull/583
2 changes: 1 addition & 1 deletion Cargo.toml
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
[package]
name = "libc"
version = "0.2.48"
version = "0.2.49"
authors = ["The Rust Project Developers"]
license = "MIT OR Apache-2.0"
readme = "README.md"
Expand Down
238 changes: 72 additions & 166 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,195 +1,101 @@
libc
====
[![Travis-CI Status]][Travis-CI] [![Appveyor Status]][Appveyor] [![Cirrus-CI Status]][Cirrus-CI] [![Latest Version]][crates.io] [![Documentation]][docs.rs] ![License]

Raw FFI bindings to platform libraries like `libc`.
libc - Raw FFI bindings to platforms' system libraries
====

[![Build Status](https://travis-ci.org/rust-lang/libc.svg?branch=master)](https://travis-ci.org/rust-lang/libc)
[![Build status](https://ci.appveyor.com/api/projects/status/github/rust-lang/libc?svg=true)](https://ci.appveyor.com/project/rust-lang-libs/libc)
[![Build Status](https://api.cirrus-ci.com/github/rust-lang/libc.svg)](https://cirrus-ci.com/github/rust-lang/libc)
[![Latest version](https://img.shields.io/crates/v/libc.svg)](https://crates.io/crates/libc)
[![Documentation](https://docs.rs/libc/badge.svg)](https://docs.rs/libc)
[![License](https://img.shields.io/crates/l/libc.svg)]
`libc` provides all of the definitions necessary to easily interoperate with C
code (or "C-like" code) on each of the platforms that Rust supports. This
includes type definitions (e.g. `c_int`), constants (e.g. `EINVAL`) as well as
function headers (e.g. `malloc`).

**NOTE:** The minimum supported Rust version is **Rust 1.13.0** . APIs requiring
newer Rust features are only available on newer Rust versions:
This crate exports all underlying platform types, functions, and constants under
the crate root, so all items are accessible as `libc::foo`. The types and values
of all the exported APIs match the platform that libc is compiled for.

| Feature | Version |
|----------------------|---------|
| `union` | 1.19.0 |
| `const mem::size_of` | 1.24.0 |
| `repr(align)` | 1.25.0 |
| `core::ffi::c_void` | 1.30.0 |
More detailed information about the design of this library can be found in its
[associated RFC][rfc].

To use `libc` at its fullest, Rust 1.30.0 is required.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1291-promote-libc.md

## Usage

First, add the following to your `Cargo.toml`:
Add the following to your `Cargo.toml`:

```toml
[dependencies]
libc = "0.2"
```

Next, add this to your crate root:
## Features

```rust
extern crate libc;
```
* `use_std`: by default `libc` links to the standard library. Disable this
feature remove this dependency and be able to use `libc` in `#![no_std]`
crates.

Currently libc by default links to the standard library, but if you would
instead like to use libc in a `#![no_std]` situation or crate you can request
this via:
* `extra_traits`: all `struct`s implemented in `libc` are `Copy` and `Clone`.
This feature derives `Debug, `Eq`, `Hash`, and `PartialEq`.

```toml
[dependencies]
libc = { version = "0.2", default-features = false }
```
## Rust version support

By default libc uses private fields in structs in order to enforce a certain
memory alignment on them. These structs can be hard to instantiate outside of
libc. To make libc use `#[repr(align(x))]`, instead of the private fields,
activate the *align* feature. This requires Rust 1.25 or newer:
The minimum supported Rust toolchain version is **Rust 1.13.0** . APIs requiring
newer Rust features are only available on newer Rust toolchains:

```toml
[dependencies]
libc = { version = "0.2", features = ["align"] }
```
| Feature | Version |
|----------------------|---------|
| `union` | 1.19.0 |
| `const mem::size_of` | 1.24.0 |
| `repr(align)` | 1.25.0 |
| `extra_traits` | 1.25.0 |
| `core::ffi::c_void` | 1.30.0 |
| `repr(packed(N))` | 1.33.0 |

All structs implemented by the libc crate have the `Copy` and `Clone` traits
implemented for them. The additional traits of `Debug, `Eq`, `Hash`, and
`PartialEq` can be enabled with the *extra_traits* feature (requires Rust 1.25
or newer):
## Platform support

```toml
[dependencies]
libc = { version = "0.2", features = ["extra_traits"] }
```
[Platform-specific documentation of libc's master branch for all supported platforms][docs.master].

## What is libc?
See [`ci/build.sh`](ci/build.sh) for the platforms on which `libc` is
guaranteed to build for each Rust toolchain. The test-matrix at [Travis-CI],
[Appveyor], and [Cirrus-CI] show the platforms in which `libc` tests are run.

The primary purpose of this crate is to provide all of the definitions necessary
to easily interoperate with C code (or "C-like" code) on each of the platforms
that Rust supports. This includes type definitions (e.g. `c_int`), constants
(e.g. `EINVAL`) as well as function headers (e.g. `malloc`).
<div class="platform_docs"></div>

This crate does not strive to have any form of compatibility across platforms,
but rather it is simply a straight binding to the system libraries on the
platform in question.
## License

## Public API
This project is licensed under either of

This crate exports all underlying platform types, functions, and constants under
the crate root, so all items are accessible as `libc::foo`. The types and values
of all the exported APIs match the platform that libc is compiled for.
* [Apache License, Version 2.0](http://www.apache.org/licenses/LICENSE-2.0)
([LICENSE-APACHE](LICENSE-APACHE))

More detailed information about the design of this library can be found in its
[associated RFC][rfc].
* [MIT License](http://opensource.org/licenses/MIT)
([LICENSE-MIT](LICENSE-MIT))

[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1291-promote-libc.md
at your option.

## Contributing

We welcome all people who want to contribute. Please see the [contributing
instructions] for more information.

[contributing instructions]: CONTRIBUTING.md

Contributions in any form (issues, pull requests, etc.) to this project
must adhere to Rust's [Code of Conduct].

[Code of Conduct]: https://www.rust-lang.org/en-US/conduct.html

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in `libc` by you, as defined in the Apache-2.0 license, shall be
dual licensed as above, without any additional terms or conditions.

## Adding an API

Want to use an API which currently isn't bound in `libc`? It's quite easy to add
one!

The internal structure of this crate is designed to minimize the number of
`#[cfg]` attributes in order to easily be able to add new items which apply
to all platforms in the future. As a result, the crate is organized
hierarchically based on platform. Each module has a number of `#[cfg]`'d
children, but only one is ever actually compiled. Each module then reexports all
the contents of its children.

This means that for each platform that libc supports, the path from a
leaf module to the root will contain all bindings for the platform in question.
Consequently, this indicates where an API should be added! Adding an API at a
particular level in the hierarchy means that it is supported on all the child
platforms of that level. For example, when adding a Unix API it should be added
to `src/unix/mod.rs`, but when adding a Linux-only API it should be added to
`src/unix/notbsd/linux/mod.rs`.

If you're not 100% sure at what level of the hierarchy an API should be added
at, fear not! This crate has CI support which tests any binding against all
platforms supported, so you'll see failures if an API is added at the wrong
level or has different signatures across platforms.

With that in mind, the steps for adding a new API are:

1. Determine where in the module hierarchy your API should be added.
2. Add the API.
3. Send a PR to this repo.
4. Wait for CI to pass, fixing errors.
5. Wait for a merge!

### Test before you commit

We have two automated tests running on [Travis](https://travis-ci.org/rust-lang/libc):

1. [`libc-test`](https://github.com/alexcrichton/ctest)
- `cd libc-test && cargo test`
- Use the `skip_*()` functions in `build.rs` if you really need a workaround.
2. Style checker
- `rustc ci/style.rs && ./style src`

### Releasing your change to crates.io

Now that you've done the amazing job of landing your new API or your new
platform in this crate, the next step is to get that sweet, sweet usage from
crates.io! The only next step is to bump the version of libc and then publish
it. If you'd like to get a release out ASAP you can follow these steps:

1. Update the version number in `Cargo.toml`, you'll just be bumping the patch
version number.
2. Run `cargo update` to regenerate the lockfile to encode your version bump in
the lock file. You may pull in some other updated dependencies, that's ok.
3. Send a PR to this repository. It should [look like this][example], but it'd
also be nice to fill out the description with a small rationale for the
release (any rationale is ok though!)
4. Once merged the release will be tagged and published by one of the libc crate
maintainers.

[example]: https://github.com/rust-lang/libc/pull/583

## Platforms and Documentation

The following platforms are currently tested and have documentation available:

Tested:
* [`i686-pc-windows-msvc`](https://rust-lang.github.io/libc/i686-pc-windows-msvc/libc/)
* [`x86_64-pc-windows-msvc`](https://rust-lang.github.io/libc/x86_64-pc-windows-msvc/libc/)
(Windows)
* [`i686-pc-windows-gnu`](https://rust-lang.github.io/libc/i686-pc-windows-gnu/libc/)
* [`x86_64-pc-windows-gnu`](https://rust-lang.github.io/libc/x86_64-pc-windows-gnu/libc/)
* [`i686-apple-darwin`](https://rust-lang.github.io/libc/i686-apple-darwin/libc/)
* [`x86_64-apple-darwin`](https://rust-lang.github.io/libc/x86_64-apple-darwin/libc/)
(OSX)
* `i386-apple-ios`
* `x86_64-apple-ios`
* [`i686-unknown-linux-gnu`](https://rust-lang.github.io/libc/i686-unknown-linux-gnu/libc/)
* [`x86_64-unknown-linux-gnu`](https://rust-lang.github.io/libc/x86_64-unknown-linux-gnu/libc/)
(Linux)
* [`x86_64-unknown-linux-musl`](https://rust-lang.github.io/libc/x86_64-unknown-linux-musl/libc/)
(Linux MUSL)
* [`aarch64-unknown-linux-gnu`](https://rust-lang.github.io/libc/aarch64-unknown-linux-gnu/libc/)
(Linux)
* `aarch64-unknown-linux-musl`
(Linux MUSL)
* [`sparc64-unknown-linux-gnu`](https://rust-lang.github.io/libc/sparc64-unknown-linux-gnu/libc/)
(Linux)
* [`mips-unknown-linux-gnu`](https://rust-lang.github.io/libc/mips-unknown-linux-gnu/libc/)
* [`arm-unknown-linux-gnueabihf`](https://rust-lang.github.io/libc/arm-unknown-linux-gnueabihf/libc/)
* [`arm-linux-androideabi`](https://rust-lang.github.io/libc/arm-linux-androideabi/libc/)
(Android)
* [`x86_64-unknown-freebsd`](https://rust-lang.github.io/libc/x86_64-unknown-freebsd/libc/)
* [`x86_64-unknown-openbsd`](https://rust-lang.github.io/libc/x86_64-unknown-openbsd/libc/)
* [`x86_64-rumprun-netbsd`](https://rust-lang.github.io/libc/x86_64-unknown-netbsd/libc/)

The following may be supported, but are not guaranteed to always work:

* `i686-unknown-freebsd`
* [`x86_64-unknown-bitrig`](https://rust-lang.github.io/libc/x86_64-unknown-bitrig/libc/)
* [`x86_64-unknown-dragonfly`](https://rust-lang.github.io/libc/x86_64-unknown-dragonfly/libc/)
* `i686-unknown-haiku`
* `x86_64-unknown-haiku`
* [`x86_64-unknown-netbsd`](https://rust-lang.github.io/libc/x86_64-unknown-netbsd/libc/)
* [`x86_64-sun-solaris`](https://rust-lang.github.io/libc/x86_64-sun-solaris/libc/)
[Travis-CI]: https://travis-ci.com/rust-lang/libc
[Travis-CI Status]: https://travis-ci.com/rust-lang/libc.svg?branch=master
[Appveyor]: https://ci.appveyor.com/project/rust-lang-libs/libc
[Appveyor Status]: https://ci.appveyor.com/api/projects/status/github/rust-lang/libc?svg=true
[Cirrus-CI]: https://cirrus-ci.com/github/rust-lang/libc
[Cirrus-CI Status]: https://api.cirrus-ci.com/github/rust-lang/libc.svg
[crates.io]: https://crates.io/crates/libc
[Latest Version]: https://img.shields.io/crates/v/libc.svg
[Documentation]: https://docs.rs/libc/badge.svg
[docs.rs]: https://docs.rs/libc
[License]: https://img.shields.io/crates/l/libc.svg
[docs.master]: https://rust-lang.github.io/libc
39 changes: 27 additions & 12 deletions ci/dox.sh
Original file line number Diff line number Diff line change
Expand Up @@ -6,28 +6,43 @@

set -ex

TARGETS=$(grep html_root_url src/lib.rs | sed 's/.*".*\/\(.*\)"/\1/'| sed 's/)//')
TARGET_DOC_DIR=target/doc
README=README.md
PLATFORM_SUPPORT=platform-support.md

rm -rf target/doc
mkdir -p target/doc
rm -rf $TARGET_DOC_DIR
mkdir -p $TARGET_DOC_DIR

cp ci/landing-page-head.html target/doc/index.html
# List all targets that do currently build successfully:
# shellcheck disable=SC1003
grep '[\d|\w|-]* \\' ci/build.sh > targets
sed -i.bak 's/ \\//g' targets
grep '^[_a-zA-Z0-9-]*$' targets > tmp && mv tmp targets

for target in $TARGETS; do
# Create a markdown list of supported platforms in $PLATFORM_SUPPORT
rm $PLATFORM_SUPPORT || true

printf '### Platform-specific documentation\n' >> $PLATFORM_SUPPORT

while read -r target; do
echo "documenting ${target}"

rustdoc -o "target/doc/${target}" --target "${target}" src/lib.rs --cfg cross_platform_docs \
--crate-name libc
#rustdoc -o "$TARGET_DOC_DIR/${target}" --target "${target}" src/lib.rs --cfg cross_platform_docs \
# --crate-name libc

echo "* [${target}](${target}/libc/index.html)" >> $PLATFORM_SUPPORT
done < targets

echo "<li><a href=\"/libc/${target}/libc/index.html\">${target}</a></li>" \
>> target/doc/index.html
done
# Replace <div class="platform_support"></div> with the contents of $PLATFORM_SUPPORT
cp $README $TARGET_DOC_DIR
line=$(grep -n '<div class="platform_docs"></div>' $README | cut -d ":" -f 1)

cat ci/landing-page-footer.html >> target/doc/index.html
set +x
{ head -n "$((line-1))" $README; cat $PLATFORM_SUPPORT; tail -n "+$((line+1))" $README; } > $TARGET_DOC_DIR/$README

# If we're on travis, not a PR, and on the right branch, publish!
if [ "$TRAVIS_PULL_REQUEST" = "false" ] && [ "$TRAVIS_BRANCH" = "master" ]; then
pip install ghp_import --install-option="--prefix=$HOME/.local"
"${HOME}/.local/bin/ghp-import" -n target/doc
"${HOME}/.local/bin/ghp-import" -n $TARGET_DOC_DIR
git push -qf "https://${GH_TOKEN}@github.com/${TRAVIS_REPO_SLUG}.git" gh-pages
fi
Loading