Use `CBindings.jl` or `Clang.jl` to build raw interface?

[jkozdon]

Right now we wrap the interface by hand, might be worth seeing if getting a raw interface would be possible using CBindings.jl and then adding a nicer layer on top of this.

I've never used CBindings.jl, but a non-trivial example is done for P4est.jl https://github.com/trixi-framework/P4est.jl. (Others?)

cc: @psanan

[vchuravy]

cc: @gnimuc who refactor Clang.jl quite heavily recently and improved the quality of the autogenerated wrappers we use for LLVM and CUDA

[jkozdon]

Thanks @vchuravy. Would you recommend Clang.jl over CBindings.jl? (Clang.jl seems more widely used?)

[jkozdon]

I was able to sort of get Clang.jl to work (didn't actually try using it).

• commit: https://github.com/JuliaParallel/PETSc.jl/commit/a71fd1b3d4ffe81efb89e5f86abe8145048c5474
• branch: https://github.com/JuliaParallel/PETSc.jl/tree/jek/gen
• 'generator.jl`
• wrapped functions

Still would require some more work to (for instance) handle all the different library types, remove the MPI stuff which we get from MPI.jl but promising!

(My understand of Clang.jl and the options is still pretty small)

[jkozdon]

After a ton of mangling, I think that I have Clang.jl working with all the libraries.

[Gnimuc]

Would you recommend Clang.jl over CBindings.jl? (Clang.jl seems more widely used?)

It depends on your use case. Clang.jl is a static binding generator. The generated code is self-contained Julia source code. CBinding.jl is more like a lightweight Cxx.jl for working with C APIs only.

[jkozdon]

Thanks. I decided to start by playing with Clang.jl which was promising.

I'm personally fine with static bindings, not sure the real advantages here for dynamic. But maybe I am just being naive?

[Gnimuc]

Feel free to open feature request issues on Clang.jl if you'd like to let it offer some facilities for your generator.

[psanan]

Another example using Clang.jl is LibCEED, e.g. code to generate bindings, doc

I would have predicted a pain point from PETSc relying on a great deal of C preprocessor logic, which might not be as amenable to automatic wrapping. Did that emerge in your Clang.jl experiments?

[Gnimuc]

@psanan any chance to upgrade libCEED's generator script to Clang.jl#master? Any feedback would be appreciated. For examples using the upcoming v0.14 API, see https://github.com/Gnimuc/GeneratorScripts.

IMO, if the C library defines a lot of macro helpers for making the C language a little bit easier to work with, then all of those helpers should be rewritten using Julialang features instead of doing a one-to-one mapping. Not to mention that this one-to-one mapping stuff is quite hard to deal with. If a package can do this, it has to "understand" both C and Julia at the source code level. This work is even not easy for a human being.

[psanan]

@Gnimuc I'm not a LibCEED dev (nor very experienced with these tools, yet) so I think e.g. @jedbrown or @pazner would have to answer that.

[Gnimuc]

Sorry. I thought you were one of the developers.

[jkozdon]

Not sure if I will run into any major hiccups, but #149 seems to be working out OK.

Will take a bit of time to move everything over the the Clang wrapped versions, and there are couple things I need to sort out, but I think it should work to use Clang.jl even with the multiple libraries.

[pazner]

@psanan any chance to upgrade libCEED's generator script to Clang.jl#master? Any feedback would be appreciated. For examples using the upcoming v0.14 API, see https://github.com/Gnimuc/GeneratorScripts.

Hi @Gnimuc, I do intend to update the LibCEED.jl generator script to use the new interface. It might take some time before I get to it.