Hi all,
Thanks to the ##rust IRC wizards, I was able to get past a code organization problem. The problem was as follows:
I have a lib crate, let's call it mylib, which has a bunch of dependencies that require a library -- somelib.
My compilation target does not include libc, which somelib makes a few calls to. What we had was a module in mylib that stubbed out the libc calls with extern { } (they do nothing basically) and we vendor the entire somelib.
Now, I have moved out somelib source to a new crate -- somelib-sys, and moved the stubbed libc extern functions to lib.rs of somelib-sys. Much nicer. In mylib i can now use somelib-sys as a dependency.
The new problem is that, in order for mylib to actually find the symbols in lib.rs of somelib-sys I have to use somelib-sys; even though I don't actually call those extern functions in mylib (only the dependencies do...). So now I have to allow unused imports.
Is there a problem with this new organization or usage of sys crate?
Linking libc is usually part of the c runtime (crt) which is also used by Rust. Therefore libc is always present even if you Rust programm is not aware of the functionality. (The libc crate is basically only some sort of header file.) Also notice, that while you might not be calling libc yourself, the Rust standard library does.
It's a little difficult to tell, what exactly you are doing. Usually a -sys crate's primary function is to simply declare a bunch of extern "C" in a fashon reassembling the libaries "somelib.h" file. In this case, you should have no problem linking it, since you are calling its functionality. The secondary function is to actually ensure that the c library itself is linked. If you have a -src crate (which only does the linking part and not the declaration) or a -sys crate which you only need to be present for other c libraries, you should make sure it gets included by an explicit extern crate somecrate statement.
An external crate dependency can be declared without binding its name in scope by using an underscore with the form extern crate foo as _ . This may be useful for crates that only need to be linked, but are never referenced, and will avoid being reported as unused.
The macro_use attribute works as usual and import the macro names into the macro-use prelude.