Skip to content

Parametrize dlopen feature names #13

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Feb 24, 2021

Conversation

milkey-mouse
Copy link
Contributor

@milkey-mouse milkey-mouse commented Feb 22, 2021

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.

@milkey-mouse
Copy link
Contributor Author

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.

Copy link
Owner

@elinorbgr elinorbgr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@milkey-mouse
Copy link
Contributor Author

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

@milkey-mouse milkey-mouse force-pushed the parametrized-feature-name branch from 69d708a to f36bca1 Compare February 22, 2021 22:56
This is useful for robustness, if someone imports just one macro from
dlib that ends up trying to call another.
@milkey-mouse milkey-mouse force-pushed the parametrized-feature-name branch from 287586b to fa1e778 Compare February 22, 2021 23:19
@elinorbgr
Copy link
Owner

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?

@milkey-mouse
Copy link
Contributor Author

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

Copy link
Owner

@elinorbgr elinorbgr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, looks pretty good, thanks!

@elinorbgr elinorbgr merged commit d707c75 into elinorbgr:master Feb 24, 2021
@milkey-mouse
Copy link
Contributor Author

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
Copy link
Owner

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

@elinorbgr
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants