Jonathan B. Coe
Jonathan B. Coe
[Kotlin](https://kotlinlang.org) is a JVM language that we could generate bindings for. This is for completeness rather than to satisfy an external request for language support.
This PR reactivates a Linux Docker build so that the Appveyor devs can investigate performance concerns. If the Appveyor build can be sped up we will re-enable Linux on Appveyor.
Bazel is a cross-platform build tool that could be extended using Skylark to support FFIG. https://bazel.build https://docs.bazel.build/versions/master/skylark/language.html
Support for some languages is better than others. Add a table to the README to make this clear and avoid wasting people's time.
Julia is a new language designed for scientific programming. It has a CFFI so should be useable with FFIG. https://julialang.org https://docs.julialang.org/en/stable/manual/calling-c-and-fortran-code/
See resolution to https://gitlab.kitware.com/cmake/cmake/issues/18005 or https://stackoverflow.com/questions/50398953/how-can-i-get-cmake-to-produce-a-build-error-if-an-expected-output-is-not-produc and implement required changes.
Java bindings should have javadoc so that the JAR file can be easily used inside IDEs. This should just be a case of generating a comment block.
Currently boost::python bindings are tested with a very rudimentary inline Python script. All of the existing Python tests should be used for boost::python testing (possibly with some transformation performed to...
It would be good to have a CMake target per FFIG binding rather than all bindings rolled into one: `add_ffig_c_library` `add_ffig_cpp_library` `add_ffig_python_library` `add_ffig_ruby_library` etc.
https://blogs.msdn.microsoft.com/dotnet/2017/11/15/nullable-reference-types-in-csharp/ Methods that return nullable sub-objects should return nullable references when they are supported.