autowrap

About

In PyD, the functions and data structures must be registered manually,
and while the same isn't true of excel-d, the latter wraps everything
in the modules reflected on. When writing code specifically for Excel,
that is clearly what the user wants (and if not it can be made private).
When wrapping pre-existing D code, however, it makes sense to opt-in instead
by requiring functions to be wrapped to be marked export. If one wants to
wrap all functions regardless of export, use version=AutowrapAlwaysExport.

There is ppyd that makes the effort
required to use pyd a lot less but that requires using a UDA. Again, when
writing code specifically for Python use this makes sense, but adds a
dependency that "dirties" pre-existing D code.

This dub package makes it possible to wrap pre-existing D code "from the outside",
imposing no dependencies on the aforementioned body of work.

autowrap also does away with the boilerplate necessary to creating a Python extension
with PyD. Things should just work.

Python versions

Since autowrap depends on PyD, the version of python to use must be specified.
You can either specify the configuration explicity, e.g.
subConfiguration "autowrap:python" "python36" or you can use the default env
configuration. In order to build using the env configuration your must first
set the relevant environment variables using the pyd_set_env_vars.{sh,bat}
scripts, which you can copy to your current working directory by running
dub run pyd:setup. See
the pyd docs for more
information.

.NET Support

Autowrap can also generate C# bindings to D libraries. Generating bindings for C# is a two-step process. First we must generate a C# compatible C-interface for the D library, then we build and run a version of the library that emits the corresponding C# interface code.

What Works:

Module Functions

Primitive Types

string

wstring

dstring

byte

ubyte

short

ushort

int

uint

long

ulong

float

double

Structs

Fields

Properties

Methods

Classes

Constructors

Fields

Properties

Methods

1-Dimensional Ranges are implemented but only lightly tested and may not work in all cases. Higher dimensional ranges are not supported.

Generating .NET Interfaces

To generate the C-interface use the following example replacing "csharp" with the dub name of your library (ex: csharp builds to libcsharp.so) and replace "csharp.library" with the name of the module you want to wrap.

To generate the C# interface use the emitCSharp mixin as follows to dump the output to a location of your choice. This mixin creates a void main() function that will need to be executed by running the code. (This is due to the inability of CTFE to write files to the disk.)