Using bindgen to support all platforms #36
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The low-maintenance state of this crate is great, but here comes a suggestion for a somewhat disruptive design change which might be worth considering.
One can argue it made more sense to fully handcraft the files in
src/os/
back when this termios crate was first written than what is the case today when the available tooling situation is better. The main drawback with handcrafted platform files are that only those explicitly listed platforms are supported. If switching to instead use bindgen, all relevant platforms should be working without the tedious and error prone task of manually translating the header file into Rust. This PR implements such a change, while still maintaining the::os::*
modules as in previous versions for well-known platforms.The one thing I knowingly didn't bother updating prior to learning your opinion is the CONTRIBUTING.md file. Hence the draft status. If this looks mostly good to you, I'll polish up the documentation too.
Even though making huge structural changes, to the best of my understanding this should not require more than a patch level update to semver versioning since all public interfaces should remain unchanged. That might require a bit more consideration prior to merging though.
Regarding crate naming, I'm hoping we can be able to reach out to @basmith and obtain have the ownership of the seemingly unused and abandoned crate currently holding the termios-sys name. Otherwise libtermios-sys is available. Sorting out crate naming is likely also blocking this to be merged.
Running
cargo test
succeeds on linux and illumos. The https://git.netizen.se/termios-rs/log/?h=wip/haiku_support branch brings termios-rs to haiku, a platform where it previously refused to build. No other platforms have been attempted by me, yet.