vlc-rs

vlc-rs copied to clipboard

issue: #6

Hi, overall this works really fine for me.

Few points:

• it might make sense to use pkg-config in the build.rs to find VLC.
• should libvlc version be features or different versions ? features allow simpler breaking change signalling but is confusing for the user (especially in the documentation) and harder to maintain.
• it might make sense to use things like bitfield_enum or rustified_enum with bindgen to use a better enum field for some variants, and have more readable wrapper code, or maybe through the ParseCallbacks in a second step ? It can also be improved through prepend_enum_name.
• should we enable enable_function_attribute_detection ?

Thank you for reviewing!

it might make sense to use pkg-config in the build.rs to find VLC.

It will be better, thanks.

should libvlc version be features or different versions ? features allow simpler breaking change signalling but is confusing for the user (especially in the documentation) and harder to maintain.

Is it the same question in #6 ? I have not yet determined.

it might make sense to use things like bitfield_enum or rustified_enum with bindgen to use a better enum field for some variants, and have more readable wrapper code, or maybe through the ParseCallbacks in a second step ? It can also be improved through prepend_enum_name.

I missed the enum generator option of bindgen. I will try it.

should we enable enable_function_attribute_detection ?

I can not find differences in generated bindings.rs between the option enabled and disabled. I think remaining default is better for now.

Hi,

Is it the same question in #6 ? I have not yet determined.

Actually yes :)

• Use pkg-config
• Because bindgen enum functions can't rename enum variants to follow rust idiomatic naming, they are not used.
• Next vlc-rs 0.4 version is for libvlc 2.* . Features are erased for a while.

I mean that vlc-rs 0.4 does not include functions added since libvlc 3.0.0. There is no problem using vlc-rs 0.4 with the new libvlc.

Are you still planning to work on this @garkimasera?

This PR works without fixes. But I have no plan for detail API design because I have no longer used libvlc in my project. I can merge this PR if bindgen version is needed.

Ok, are you still planning to work on vlc-rs in the future? I think a rust binding for the libvlc ecosystem would be good.

I cannot review PRs that depend on the latest libvlc API specification. So, transferring or forking this repository will be the best choice for me.

I cannot review PRs that depend on the latest libvlc API specification. So, transferring or forking this repository will be the best choice for me.

Transferring to code.videolan.org/videolan and the ownership of vlc-rs crate to Mfkl is probably a good idea then! Do you have private projects depending on the current state, and constraints that you would like to be accounted?

@garkimasera You can mail me at [email protected].

OK, I'll invite new owner to vlc-rs and libvlc-sys.

Do you have private projects depending on the current state, and constraints that you would like to be accounted?

There are not any constraints.