Deimos
Deimos is an endeavor to host and maintain D bindings for popular non-D libraries and projects, notably which have a C ABI.
The original proposal for Deimos can be found in DIP12.
Contents
Rationale
Having a central place for bindings allows them to be:
- easily discovered;
- maintained by the community, even past the original author's interest in the project.
Agreeing on a common layout and conventions will also make usage and contribution easier.
Hosting bindings under the D-Programming-Deimos organization is orthogonal to, and provides benefits in addition to, publishing the bindings on the Dub registry (code.dlang.org).
Description
A repository for each project is created under https://github.com/D-Programming-Deimos.
Following these conventions should maximize consistency and simplify distribution / usage:
Directory structure
Repositories have the following directory structure:
|--- library name (repository root) |--- README.md |--- dub.sdl |--- C |--- foo.h |--- bar |--- baz.h |--- deimos |--- foo.d |--- bar |--- baz.d
The C directory should contain a copy of the original C headers that were translated. Doing so allows updating them to newer versions easily, as only the diffs between the old and new C headers need to be translated and applied to the D bindings.
The layout of the C directory corresponds to /usr/include
on UNIX machines. Thus, if a C header file would be installed to /usr/include/bar/baz.h
, in the repository it should be added as C/bar/baz.h
.
The D module/package names should map such that #include <path/to/header.h>
should correspond to import path.to.header;
.
Recommendations
- Each library should contain a README file (
README
, orREADME.md
for Markdown syntax) in the root folder.
The README file should contain exact source and version of the C library.
Any specific notes regarding the usage or translation of the bindings should also be placed there.
- Every library should contain a simple D example under an examples directory.
Translation
- Deimos repositories should aim to provide 1:1 bindings of C APIs, without any higher-level wrapping. Higher-level wrappers can be included alongside low-level ones, but are best provided as separate projects / repositories on top of the Deimos bindings.
Rationale:- Low-level bindings will generally satisfy the constraints of all D projects, regardless of platform / architecture / toolchain, and usable from
nothrow
/@nogc
/-bettelC
code. Higher-level bindings will generally compromise on some of these constraints in order to provide a more typical D API. - Low-level bindings, being a 1:1 translation of C header files, are generally uncontroversial (as in, there isn't really more than one way to write them). Higher-level wrappers can be potentially written using a variety of approaches / paradigms / style, thus there not being one single obviously correct way to write them.
- Low-level bindings will generally satisfy the constraints of all D projects, regardless of platform / architecture / toolchain, and usable from
- The D import files should try to do as least modifications as possible to simplify updates of the C headers. This includes leaving comments intact (unless e.g. adapting them to DDoc syntax).
- The copyright for the D import files should match the one being used by the C header as they constitute a derived work.
- If the C header file has a name that is a D keyword, an underscore will be appended to the D module name.
- If a C type name matches a C function name (e.g.
stat
), the type name will have a_t
appended (e.g.stat_t
). - Ideally, translated header modules should not require linkage of any D binary. Macros and inline functions can be translated as templates, e.g.:
- C:
#define GET(x) x.value
- D:
int GET(X)(X x) { return x.value; }
One way to test if your bindings satisfy this property is to write a program making use of these bindings, and compile it without including the bindings' source files in the compilation, e.g.
dmd -Lmytestlib.lib test.d
(as opposed to usingdub
,rdmd
, ordmd -i
). - C:
Versioning
Version tags should match the ones being used by the C headers.
For repositories providing bindings for projects which use a versioning scheme incompatible with semantic versioning, the preferred approach is to use semantic versioning and append the original library version past a +
sign (example: OpenSSL).
Submitting
To propose a new binding project to be added to Deimos, contact a member of the D-Programming-Deimos organization:
https://github.com/orgs/D-Programming-Deimos/people
If you are already a member of D-Programming-Deimos, consider making your membership public, so that you can be contacted by submitters.
Contributing
To submit updates or improvements, send a pull request as usual.
If you get no response to your pull request, or if you would like to be added as a project maintainer, ping an organization member.