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

Deprecate in favor of common ocaml-posix #5

Open
toots opened this issue Jan 5, 2020 · 1 comment
Open

Deprecate in favor of common ocaml-posix #5

toots opened this issue Jan 5, 2020 · 1 comment

Comments

@toots
Copy link

toots commented Jan 5, 2020

Hi,

Following a conversation with the ocaml-ctypes maintainer here: yallop/ocaml-ctypes#620 I have worked on a consolidated ocaml-posix module.

This module aims at giving a unified structure to all existing POSIX bindings, with support for both high-level consumer API as well as low-level ctypes APIs.

Also, these modules take advantage of the most recent dune support which, in particular, allows for powerful compilation configuration, including multi-layered builds and config tests. which makes it possible to write all these bindings without writing a single C file. The gist of this scaffolding is described here: https://medium.com/@romain.beauxis/advanced-c-binding-using-ocaml-ctypes-and-dune-cc3f4cbab302

The posix-types module included in ocaml-posix provides the exact same API as this module. Considering that this module has not been updated for a while and that the new one would be a drop-in, consolidated replacement, would you be okay to deprecate this module to be replaced by the new one?

Likewise, the ocaml-ctypes maintainers would deprecated their own PosixTypes module, leading to a single, unified modern implementation.

It is, of course, my intent to give all previous maintainer commit access to the new repository so the work can continue jointly there.

Let me know what you think!
Romain

@toots toots changed the title Replace, deprecate in favor of common ocaml-posix Deprecate in favor of common ocaml-posix Jan 5, 2020
@yallop
Copy link
Owner

yallop commented Jan 6, 2020

Considering that this module has not been updated for a while and that the new one would be a drop-in, consolidated replacement, would you be okay to deprecate this module to be replaced by the new one?

Yes, I'm happy to do that. What do you think is the clearest way of deprecating it in practice? (Are a post-install note in the OPAM file and a note in the README sufficient?)

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

No branches or pull requests

2 participants