-
Notifications
You must be signed in to change notification settings - Fork 9
Description
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-capicrate 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?).