Parametrize dlopen feature names

[twilligon]

This PR adds an argument to the beginning of dlib's macros which specifies the name of the feature that switches between dlopen and linking the library at build time. In this branch, the specified feature lives on the crate using dlib, which means crates no longer have to enable the dlopen feature on dlib. For example, in this snippet, the library is linked at build time if the dlopen-foo feature is disabled on the crate it resides in:

external_library!("dlopen-foo",Foo,"foo",
functions:fn foo() -> c_int,);

See the README for more information, and also Smithay/client-toolkit#178 for context.

[twilligon]

BTW, I tested building smithay-client-toolkit and wayland-rs against this branch and it works fine. This keeps the old behavior (dlopen-ing everything) when dlib/dlopen is enabled, and it has almost the same behavior if not; only if you give a feature argument as I did in the above example does the behavior change.

[elinorbgr]

Looks good overall, just two points. Thanks a lot for having taken the time to update the Readme as well!

[twilligon]

The way I've written ffi_dispatch it'll only work on rust 1.43 and up, is that OK?

[elinorbgr]

The way I've written ffi_dispatch it'll only work on rust 1.43 and up, is that OK?

It is due to the cfg attributes on statements? Can't we push that further by introducing blocks, like so:

#[cfg(...)]
{
// code here
} 

IIRC this is accepted by older compilers as well, no?

[twilligon]

I take it back, the existing cfg statements work fine. It's if statements that don't work in rust 1.41.

[elinorbgr]

Alright, looks pretty good, thanks!

[twilligon]

Thanks. Could you cut a new release (say 0.5.0) so these changes can start to trickle downstream? I can update my PR on smithay-client-toolkit, for example.

[elinorbgr]

Yes, I'm just preparing some cosmetic additions before the release, I'll release it soon.

[elinorbgr]

0.5.0 is now out, and if no further issues with it are met, I'll probably make it into 1.0.0 later.