Skip to content
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

drm-sys: generate powerpc64 and riscv64 bindings #170

Closed
wants to merge 1 commit into from

Conversation

alyssais
Copy link
Contributor

It's really important to have pregenerated bindings available for platforms, because even though the use_bindgen option exists, it's not possible to set it through Cargo when building something that indirectly depends on drm-sys through a crate that doesn't set the option.

Here, I've added bindings for the two platforms I'm easily able to cross compile for that weren't already present.


Maybe use_bindgen should be the default if no pregerenated bindings for the platform are available, so somebody trying to build e.g. cosmic-comp on a different architecture isn't totally out of luck?

It's really important to have pregenerated bindings available for
platforms, because even though the use_bindgen option exists, it's not
possible to set it through Cargo when building something that
indirectly depends on drm-sys through a crate that doesn't set the
option.

Here, I've added bindings for the two platforms I'm easily able to
cross compile for that weren't already present.
@Drakulix
Copy link
Member

It's really important to have pregenerated bindings available for platforms, because even though the use_bindgen option exists, it's not possible to set it through Cargo when building something that indirectly depends on drm-sys through a crate that doesn't set the option.

You should be able to just depend on drm-sys yourself and enable the feature. As long as you use the same version, cargo will no include the dependency twice, as it considers features to be purely additive.

That said these bindings seem useful. Are they generated on ubuntu 22.04. as well (or with the same libdrm-version at least)? Because otherwise this could expose a different feature-set for these architectures, than for all others.

@rjzak
Copy link

rjzak commented Sep 27, 2023

You should be able to just depend on drm-sys yourself and enable the feature. As long as you use the same version, cargo will no include the dependency twice, as it considers features to be purely additive.

The problem with this is the crates and sub-crates which end up depending on drm causing problems. For example, I'm trying to use slint, but that depends on i-slint-backend-winit, which depends on softbuffer, which depends on drm. So if drm had the bindings, it would resolve headaches for the many downstream crates.

Or, have something like this in the Cargo.toml for drm to enable the feature for non-x86_64 targets:

[target.'cfg(all(target_os = "linux", not(target_arch = "x86_64")))'.dependencies]
drm-sys = { features = ["use_bindgen"] }

I have this in my project, which is silly because it doesn't directly depend on softbuffer or drm, yet I have to have drm in my Cargo.toml so I can test and use my project on my ppc64le desktop.

@rjzak
Copy link

rjzak commented Sep 27, 2023

Would this PR also work for PowerPC64LE?

@ids1024
Copy link
Member

ids1024 commented Nov 3, 2023

With #176 separate bindings are no longer required for each architecture, and riscv64 is one of the architectures it checks on CI to make sure the bindings are match.

@alyssais
Copy link
Contributor Author

alyssais commented Nov 3, 2023

Excellent!

@alyssais alyssais closed this Nov 3, 2023
@alyssais alyssais deleted the bindings branch November 3, 2023 16:41
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.

4 participants