Generate bindings using Clang.jl and reimplement C wrappers in Julia

[Gnimuc]

This PR implements @eschnett's idea in #5 (comment).

I did this mainly for testing JuliaInterop/Clang.jl#278, and I do find bugs related to C's bitfields.

[codecov-io]

Codecov Report

Merging #18 (707b7ec) into master (0ce2779) will decrease coverage by 63.53%.
The diff coverage is 28.70%.

@@             Coverage Diff             @@
##           master      #18       +/-   ##
===========================================
- Coverage   95.55%   32.02%   -63.54%     
===========================================
  Files           3        5        +2     
  Lines          45      356      +311     
===========================================
+ Hits           43      114       +71     
- Misses          2      242      +240     

Impacted Files	Coverage Δ
src/old_bindings.jl	0.00% <0.00%> (ø)
src/LibQhull.jl	17.84% <17.84%> (ø)
src/bindings.jl	95.65% <95.65%> (-4.35%)	⬇️
src/MiniQhull.jl	91.66% <100.00%> (-8.34%)	⬇️
src/load.jl	0.00% <0.00%> (-83.34%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0ce2779...707b7ec. Read the comment docs.

[eschnett]

How is the program flow regarding calling malloc and free? I see that the code calls malloc, but never calls free. It also seems to me that it would be easy to call malloc many times in a program. Do we need an explicit qhull_handler_free function? Or could this be handled automatically by registering a finalizer?

[Gnimuc]

Libc.free is called within delaunay_free. When porting the code, I actually hit a problem that there is no stderr(be of type Ptr{FILE}) in Libc.

[Gnimuc]

OK, finally got CI passed on macOS. The hard-coded jmp_buf should not work on other platforms.

[Gnimuc]

Clang.jl can now work in a cross-platform mode. It can download BB's gcc-shards and setup a cross-compile environment(i.e. system headers) to generate bindings for different platforms.

Tests passed on both Linux-x86_64 and macOS, but no luck on Windows. However, I guess the failure on Windows is not due to the wrong size of qhT.

@stevengj you might be interested in this.

[fverdugo]

Hi @Gnimuc!

I am not convinced if this is the approach we want to adopt to make MiniQHull more portable.

My favorite solution would be to wait until this is taken into account in QHULL : qhull/qhull#86
and, in the mean time, to distribute the MiniQHullWrapper via BinaryBuilder.jl

[fverdugo]

I would perhaps invest efforts in distributing the MiniQHullWrapper via BinaryBuilder.jl.

In that way, MiniQHull would only depend on qhull_jll and MiniQHullWrapper_jll (or whatever name we end up with). The letter dependency, could be eventually removed once this qhull/qhull#86 is fixed.

[Gnimuc]

Never mind. As I wrote in the OP, the main purpose of this PR is to test the new features of Clang.jl.

The API of qhull/qhull is not designed for the non-C family languages, those macros like FORALLpoints are really hard to translate...🤢 I'd say they should provide a whole new set of high-level C APIs.

I'm closing this now, for anyone being interested in auto-generating bindings with Clang.jl, the latest generated code can be always checked at this link.

[fverdugo]

Yes, the macros like FORALLpoints are the main reason we introduced the C wrappers!

[Gnimuc]

What I'm currently experimenting with is that

1. partially resurrect Cxx.jl, so Julia becomes a "C-family language" and one can do Julia-C interop seamlessly;
2. create a package for analyzing the code and auto-generating the corresponding C89 wrapper library based on the analysis result;
3. we definitely don't want to bundle an LLVM/Clang compiler in the release version of our package, so the package should also generate corresponding BB scripts.

In this way, we can use LLVM/Clang in the dev mode for interactively developing the package and publish the final lightweight release version of the package based on BB artifacts.