Wrap existing D code for use in other environments such as Python, Excel, and .NET.
To build and test all the code, run ci/test-all.sh
There are projects already to make it possible to use D code from Python and from Excel.
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.
To wrap for Python, make a dub dynamicLibrary project with one file:
import autowrap.python;
mixin(
wrapDlang!(
LibraryName("mylibrary"),
Modules("my.module1", "my.module2", /* ... */),
)
);
Assuming the dub package name is also "mylibrary", you should get libmylibrary.so/mylibrary.dll. If the former, rename it to mylibrary.so and you'll be able to use it from Python:
import mylibrary
mylibrary.func1()
The camelCase D functions are wrapped by snake_case Python functions, but struct members have the same names.
It is also possible to wrap all functions regardless of their export
status on a
module-by-module basis. To do so, instead of using a string to designate the module,
do this instead:
Modules("my.module1", Module("my.module2", Yes.alwaysExport))
To wrap for Excel:
import autowrap.excel;
mixin(
wrapAll!(
"my.module1", "my.module2", /* ... */
)
);
The camelCase D functions will be PascalCase in Excel.
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.
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.
1-Dimensional Ranges are implemented but only lightly tested and may not work in all cases. Higher dimensional ranges are not supported.
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.
import csharp.library;
import autowrap.csharp;
mixin(
wrapCSharp("csharp",
Modules(
Module("csharp.library")
)
)
);
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.)
mixin(
emitCSharp(
Modules(
Module("csharp.library")
),
OutputFileName("Wrapper.cs"),
LibraryName("csharp"),
RootNamespace("csharp")
)
);
module csharp.wrapper;
import csharp.library;
import autowrap.csharp;
immutable Modules modules = Modules(Module("test"));
mixin(
wrapCSharp(
Modules(
Module("csharp.library")
),
OutputFileName("Wrapper.cs"),
LibraryName("csharp"),
RootNamespace("csharp")
)
);