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

Prepare ctypes 0.9.2 #444

Merged
merged 2 commits into from Sep 12, 2016
Merged

Prepare ctypes 0.9.2 #444

merged 2 commits into from Sep 12, 2016

Conversation

yallop
Copy link
Owner

@yallop yallop commented Sep 12, 2016

No description provided.

@yallop yallop merged commit d87d527 into yallop:master Sep 12, 2016
@yallop yallop deleted the prepare-0.9.2 branch September 12, 2016 12:28
@dbuenzli
Copy link
Contributor

Would you mind having a look at opkg ocamldoc ctypes to see if the errors are fixable (they may not be) ?

@dbuenzli
Copy link
Contributor

> opkg ocamldoc ctypes 
File "/Users/dbuenzli/.opam/4.03.0/lib/ctypes/cstubs_internals.mli", line 15, characters 13-29:
Error: Unbound module Ctypes_ptr
1 error(s) encountered
File "/Users/dbuenzli/.opam/4.03.0/lib/ctypes/ctypes_static.mli", line 39, characters 22-47:
Error: Unbound module Ctypes_bigarray
1 error(s) encountered
File "/Users/dbuenzli/.opam/4.03.0/lib/ctypes/dl.mli", line 44, characters 48-64:
Error: Unbound module Ctypes_ptr

@yallop
Copy link
Owner Author

yallop commented Sep 12, 2016

I'm not sure that the errors are fixable, unfortunately: the problems are with references to internal modules for which the cmi/cmt/cmti files are deliberately not installed.

@dbuenzli
Copy link
Contributor

Ok but are these interfaces supposed to be used by end-users ? If not you could avoid installing them. FWIW here's the current rendering you get with ctypes.

@dbuenzli
Copy link
Contributor

In general opkg will consider whatever cmti or mli file installed as a wish from the package to be included in the API documentation.

@yallop
Copy link
Owner Author

yallop commented Sep 13, 2016

The difficulty arises with modules whose types need to be exposed so that generated code can be type-checked but that are not intended to be used directly by end users. It sounds like the best thing is to install only cmi (not cmti) files for those modules. #445 makes that change.

@dbuenzli
Copy link
Contributor

Note that eventually I plan to add OPAMv2 directives to be specified in your package file to guide a bit what opkg does e.g. we could have an x-opkg-doc-exclude: <list of cmti/mli> but if the use cases are low I prefer not to.

@dbuenzli
Copy link
Contributor

Just one question about about the changes you made to Dl. Do the changes make sense from an API point of view or did opkg force something on you you didn't want to do ?

@yallop
Copy link
Owner Author

yallop commented Sep 13, 2016

The changes make sense from an API point of view. It seems unreasonable to expose functions in the public interface if those function have types whose names aren't also exposed. So I changed the type of Dl.dlsym to only use public types.

@dbuenzli
Copy link
Contributor

Ok thanks.

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.

None yet

2 participants