bindings generated with Clang.jl

[ranocha]

This basically uses the setup from https://github.com/trixi-framework/p4est-bindings-clang-jl.

Whenever we recognize something new in the source code related to this process, we should leave notes prefixed by # TODO: Clang.

Closes #31, closes #39
Closes #29, closes #33, closes #41

Open questions and TODOs

• Make it explicit what we are using from P4est_jll
  • P4est_jll since we export it
  • libp4est
  • Done in make explicit what we are using from P4est_jll #53
  • Update generator scripts in dev accordingly
• Naming scheme: Most objects are pointers by default, also in p4est. Thus, we write p4est for the pointer and p4est_obj = unsafe_load(p4est).
• Build binaries for OpenMPI_jll.jl in P4est_jll.jl?
  • We decided not to do this at the moment
• How do we want to support different versions of the libp4est library (P4est_jll, local builds)? How do we want to support possibly different (pre-generated) bindings, e.g., to support different versions of p4est?
  • With Preferences.jl (similar to the new version of MPI.jl)? Seems like the best choice right now
  • With environment variables checked during the build stage (status quo)?
  • Something else?
  • We need to be able to use a local built of p4est (load a custom libp4est.so with user-specified path)
• Do not store the p4est header files in dev but set up artifacts to download the correct files instead - with the option to use a set of header files specified by the user when generating new bindings
• Get rid of the old stuff in deps (deps_disabled) and keep only the files relevant for the new setup
• Update CI system
  • Setup in https://github.com/trixi-framework/P4est.jl/blob/main/.github/workflows/ci.yml
  • We need to run tests on 3 major platforms, different versions of Julia, different configuration options (P4est_jll, local built of p4est, and different bindings (later))
• Fix Documenter
• How do we get p4est_package_id? p4est-bindings-clang-jl#3
• Update docs (README.md) and news
  • A simple usage example
  • Description of basic translation rules
  • How to use P4est.jl on a cluster
    • Set MPI.jl to local MPI installation
    • Use local built of p4est
• Fix macro stuff
  Instead of using const MPI_SUCCESS = C_NULL at the beginning of module LibP4est, we should have the correct definitions using stuff from MPI.jl
• Update required CI checks
• Remove dev/LibP4est.jl
• What to do with sc_MPI_Comm types?
  • comm and others
  • Or remove sc stuff?
• High-level overview in the docs
• Document that sc_MPI_Comm is mapped to MPI.MPI_Comm
• Merge this PR
• Make a breaking release or a new package?
  • According to juliahub.com, Trixi.jl (and Trixi2Vtk.jl) are the only dependents of P4est.jl, so creating a breaking release should be fine. The only advantage of a new package would be that both could be used in parallel if others don't update.

Enhancements that can be made after this PR are collected in #54.

[codecov]

Codecov Report

Merging #49 (d6dad0a) into main (b729031) will decrease coverage by 95.24%.
The diff coverage is 91.66%.

@@             Coverage Diff             @@
##              main     #49       +/-   ##
===========================================
- Coverage   100.00%   4.75%   -95.25%     
===========================================
  Files            1       2        +1     
  Lines            1    1494     +1493     
===========================================
+ Hits             1      71       +70     
- Misses           0    1423     +1423     

Flag	Coverage Δ
unittests	4.75% <91.66%> (-95.25%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/LibP4est.jl	3.98% <ø> (ø)
src/P4est.jl	92.30% <91.66%> (-7.70%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[sloede]

Wow, this is really a great step forward towards getting out of this binding generation hellhole we have been stuck in thus far 👍👍👍 (which, of course, is mostly my fault 🙈). I have left a few comments, but I think there's nothing that is a real blocker and most of them are mere suggestions.

Thanks a lot for the great work!

[sloede]

LGTM! If all tests pass, this can be merged!

[sloede]

I think this can be merged 🎉. The horrible code coverage is expected 😬

[ranocha]

Thanks a lot for your review, @sloede 🥳