NanoQL.Bind 2.3.0

NanoQL.Bind

nanoql-bind: the generator and native build behind nanoql's C interface, its Python wheel and its Excel add-in, for a library of your own built on nanoql. It compiles your assembly with nanoql's into one native library with Native AOT, your functions beside nanoql's under a prefix of your own, and writes the C header, the Python package or the Excel add-in over it.

dotnet tool install --global NanoQL.Bind

It needs a .NET 10 SDK of the 10.0.14 release or later, such as 10.0.114 or 10.0.403 (an earlier one builds on a Native AOT compiler NuGet's audit flags), and, for a native build, the platform's C toolchain: on Windows, Visual Studio's C++ tools with the Visual Studio Installer's folder on PATH.

A library of your own

Your assembly, Acme.dll, references the NanoQL and NanoQL.Extensions packages, with <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> in its project so that its build output holds nanoql's two assemblies beside it. In any folder:

nanoql-bind build --rid win-x64 --out acme-native \
  --assembly nql=bin/NanoQL.dll --assembly nql=bin/NanoQL.Extensions.dll --assembly acme=bin/Acme.dll

acme-native/lib/ holds the library, nanoql's functions (nql_...) and yours (acme_...), and acme-native/include/ the C and C++ headers: nanoql.h and acme.h, and nanoql.hpp and acme.hpp, whose classes extend nanoql's (acme::ExponentialCurve is a nanoql::YieldTermStructure); nanoql-bind cpp --out <folder> with the same --assembly arguments writes the C++ headers alone. The library is compiled against the nanoql assemblies you give, from one folder, so its nanoql is the one your assembly was built on; given no --assembly, the tool builds nanoql's own library from the copies beside it.

Python: with nanoql's wheel installed (pip install nanoql), the same --assembly arguments write your package, acme, beside the folder --out names; the library goes into its lib/:

nanoql-bind python --out py/nanoql \
  --assembly nql=bin/NanoQL.dll --assembly nql=bin/NanoQL.Extensions.dll --assembly acme=bin/Acme.dll
mkdir py/acme/lib && cp acme-native/lib/nanoql.dll py/acme/lib/

With py on PYTHONPATH, import acme loads that library in place of the wheel's, so import it before making any nanoql object; acme.ExponentialCurve(...) is then a nanoql.YieldTermStructure. The installed wheel is still the nanoql imported: py/nanoql/ holds only the generated modules it already carries. On Linux and macOS the library is libnanoql.so or libnanoql.dylib.

Excel: with the same --assembly arguments, nanoql-bind excel build --out <folder> builds an Excel add-in holding your worksheet functions with nanoql's (=acmeExponentialCurve(...) beside =nqlYieldTermStructureDiscount(...)), restoring its runtime, NanoQL.Excel, from NuGet.

The tool carries what it needs beside it: nanoql's two assemblies, its roles table, the names nanoql has released, which never move, and the native host's project. The commands that work on nanoql's own repository (update, check, freeze) refuse outside it. The rules for what crosses and how it is named are in the bindings guide and the Excel guide.

How it is checked

The core's results are checked against QuantLib 1.44, using test vectors generated by QuantLib's Python package and by QuantLib built from source; the extensions ported from QLNet are checked against QLNet 1.13.2. What the checks cover, per module, is on the validation page.

More

• Source and issues, and the changelog.

License

Apache 2.0. nanoql is derived from QuantLib. The package carries LICENSE, NOTICE and THIRD_PARTY_NOTICES.md, which keep the copyright notices and licences of QuantLib and of the other code it carries; a library it builds carries the .NET runtime's too, which Native AOT compiles into it.