Difference between revisions of "Deimos"

From D Wiki
Jump to: navigation, search
(Improve formatting, add clarifications)
Line 1: Line 1:
Deimos is an endeavor to host and maintain D bindings for popular libraries and projects, notably which have a C ABI.
+
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]].
 
The original proposal for Deimos can be found in [[DIP12]].
Line 11: Line 11:
  
 
Agreeing on a common layout and conventions will also make usage and contribution easier.
 
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 ==
 
== Description ==
  
A repository for each project is created under https://github.com/D-Programming-Deimos. It should have the following directory structure:
+
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)
 
  |--- library name (repository root)
Line 30: Line 38:
 
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 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 <tt>/usr/include/bar/baz.h</tt>, in the repository it should be added as <tt>C/bar/baz.h</tt>.
+
The layout of the C directory corresponds to <code>/usr/include</code> on UNIX machines. Thus, if a C header file would be installed to <code>/usr/include/bar/baz.h</code>, in the repository it should be added as <code>C/bar/baz.h</code>.
 +
 
 +
The D module/package names should map such that <code>#include &lt;path/to/header.h&gt;</code> should correspond to <code>import path.to.header;</code>.
 +
 
 +
=== Recommendations ===
 +
 
 +
* Each library should contain a README file (<code>README</code>, or <code>README.md</code> for Markdown syntax) in the root folder.<br>The README file should contain exact source and version of the C library.<br>Any specific notes regarding the usage or translation of the bindings should also be placed there.
  
The D module/package names should map such that <tt>#include &lt;path/to/header.h&gt;</tt> should correspond to <tt>import path.to.header;</tt>.
+
* Every library should contain a simple D example under an examples directory.
  
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 [https://dlang.org/spec/ddoc.html DDoc] syntax).
+
=== Translation ===
  
Translated header should not require linkage of any D binary. Macros can be written as templates, e.g.:
+
<ul>
 +
<li>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 [https://dlang.org/spec/ddoc.html DDoc] syntax).
  
C: #define GET(x) x.value
+
<li>The copyright for the D import files should match the one being used by the C header as they constitute a derived work.</li>
D: int GET(X)(X x) { return x.value; }
 
  
Version tags should match the ones being used by the C headers.
+
<li>If the C header file has a name that is a D keyword, an underscore will be appended to the D module name.
 +
 
 +
<li>If a C type name matches a C function name (e.g. <code>stat</code>), the type name will have a <code>_t</code> appended (e.g. <code>stat_t</code>).
  
The copyright for the D import files should match the one being used by the C header as they constitute a derived work.
+
<li>Ideally, translated header modules should not require linkage of any D binary. Macros and inline functions can be translated as templates, e.g.:
  
If the C header file has a name that is a D keyword, an underscore will be appended to the D module name.
+
<ul>
 +
<li><b>C</b>: <code>#define GET(x) x.value</code>
 +
<li><b>D</b>: <code>int GET(X)(X x) { return x.value; }</code>
 +
</ul>
  
If a C type name matches a C function name (stat), the type name will have a "_t" appended.
+
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. <code>dmd -Lmytestlib.lib test.d</code> (as opposed to using <code>dub</code>, <code>rdmd</code>, or <code>dmd -i</code>).
 +
</ul>
  
== Recommendations ==
+
=== Versioning ===
  
Each library should contain a README in the root folder. The README file should contain exact source and version of the C library. Furthermore, it should contain specific notes about the usage of the D import file.
+
Version tags should match the ones being used by the C headers.
  
Every library should contain a simple D example under an examples directory.
+
For repositories providing bindings for projects which use a versioning scheme incompatible with semantic versioning,
  
 
== Submitting ==
 
== Submitting ==
Line 68: Line 88:
  
 
If you get no response to your pull request, or if you would like to be added as a project maintainer, ping an [https://github.com/orgs/D-Programming-Deimos/people organization member].
 
If you get no response to your pull request, or if you would like to be added as a project maintainer, ping an [https://github.com/orgs/D-Programming-Deimos/people organization member].
 
 
  
 
[[Category:Binding]]
 
[[Category:Binding]]

Revision as of 15:11, 24 January 2019

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.

Rationale

Having a central place for bindings allows them to be:

  1. easily discovered;
  2. 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, or README.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

  • 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 using dub, rdmd, or dmd -i).

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,

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.