Skip to content

capi: move to a subcrate #290

@cyphar

Description

@cyphar

I suspect that a far more preferable approach will be to relicense the core Rust code as MPL-2.0 (which is still copyleft, but friendly to Rust and other modern languages that struggle to make static linking work in an LGPL-friendly way) and then have a separate pathrs-capi crate which implements the C API purely using the public API (and is still LGPLv3+ licensed).

The cross-crate coverage issue is still a little up in the air...

Originally posted by @cyphar in #50

We've done the relicensing work in #255, now it's time for the crate split...

It turns out that cargo llvm-cov will report cross-crate coverage if the crates are in the same namespace, so this is really not an issue at all. The main issue I can see is that we will need to have a separate pathrs-tests crate that tests both pathrs and pathrs-capi because the plan is for pathrs-capi to not be publishable and thus we cannot depend on it in the tests for pathrs. While this is seems trivial, quite a few of our tests rely on internal-only methods and information that will not be exported outside of our crate.

Of course, we can get around this by making a _test feature which changes the visibility (like https://crates.io/crates/visibility or https://crates.io/crates/instability or things we might export in the future like ErrorKind::errno?).

Metadata

Metadata

Assignees

No one assigned

    Labels

    api/cffiRelated to the C-FFI API.packagingIt's only packaging!

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions