We can easily, and precisely, list bin → lib (→ lib) dependencies by using cargo-udeps. We don't even need to parse source code of the bin by ourselves to find "dependencies".
Drawbacks
With this plan, we would write "extern crate" usages as follwing. "Bundlers" would have to process this format. Also I'm not sure it is the best way to expand multiple crates.
extern crate __acl_foo as foo; // refer to this!
↓ some tool (including expand.py)
/*extern crate __acl_foo as foo;*/use crate::acl_foo as foo; // refer to this!
This kind of crate is very incompatible with @kuretchi's cargo-simple-bundler. If we seriously follow the plan, we force cargo-simple-bundler to do:
Ahead of #63.
This PR splits the 17 modules into separate small crates like @ngtkana's ac-adapter-rs.
It aims to make development of "bundlers" that works with ac-library-rs like this easier.
https://judge.yosupo.jp/submission/28576
Benefits
bin
→lib
(→lib
) dependencies by using cargo-udeps. We don't even need to parse source code of thebin
by ourselves to find "dependencies".Drawbacks
With this plan, we would write "extern crate" usages as follwing. "Bundlers" would have to process this format. Also I'm not sure it is the best way to expand multiple crates.
↓ some tool (including
expand.py
)This kind of crate is very incompatible with @kuretchi's cargo-simple-bundler. If we seriously follow the plan, we force cargo-simple-bundler to do:
lib_a::foo
→lib_b
(orlib_b::bar
) dependencies.lib
crates.We would have to
publish
18 crates.This change may interfere with manual copy-and-paste.
expand.py
. It would continue working, and it is easier to use than copy-and-pasting by hand.