More meson.build adjustments; decouple C++ and python wrapper code

[woodtp]

Migrating some modfications I've been carrying around locally:

• Indentation: tabs -> 2 spaces per style guide
• foreach loop for the extension modules
• Removes cpp_args
  • Migrate c++ standard specification to project(). Can now be overridden from the CLI with:
    • meson setup ... -Dcpp_std=<version>
  • Global project argument for -DUSE_MPI
  • Removed -fPIC. Meson handles this for us.
• Set default buildtype to 'release' in project()
  • It can be overridden with meson setup ... -Dbuildtype=debug
• Add -march=native global project argument, conditionally.
  • Since we don't distribute binaries and expect users to compile pyo3 for themselves, I don't see a reason not to include this flag as it can only help performance. At worst, it does nothing.

Development Headers and Shared Library

meson.build has been configured to produce metadata for pkgconfig that will be installed under your chosen prefix: <prefix>/lib/pkgconfig/pyorbit3.pc. This can be discovered by pkgconfig for external projects to properly find development headers and link against libpyorbit3.

To install pyorbit in a conda environment:

meson setup build --prefix=$CONDA_PREFIX
meson compile -C build
meson install -C build

To uninstall

cd build
ninja uninstall

After installation, headers can be found under <prefix>/include/pyorbit3.

TODO

• Example external project skeleton

[woodtp]

Accidentally closed somehow

[woodtp]

Working to extend this PR to add support for 1st-party extensions, e.g., https://github.com/PyORBIT-Collaboration/laser-stripping for @tvgorlov.

[woodtp]

Fixed. All CI checks are passing.

So, it looks like I'm touching lots of files, but majority of the file diffs are just renaming instances of "Python.h" to <Python.h> and same for <structmember.h>.

There are some actual changes to core, though. My goal was to create separation between C++ backend and python wrapper logic in the meson.build. When I tried to do that haphazardly, I realized that, for example, Bunch actually requires some of the wrapper code for handling the MPI comm. Personally, I think that anything Python-related should be completely separated from the core, and the wrap_*.cc implementation should solely handle translating things for the python interpreter.

Creating that separation opens up the possibility to create bindings for other languages if desired (Julia?), or use another library like pybind/nanobind. In the end, we now have a shared library for the pyorbit core, which does not link against libpython at all:

❯ otool -L build/src/libpyorbit3.dylib                          (pyo3)
build/src/libpyorbit3.dylib:
	@rpath/libpyorbit3.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libfftw3.3.dylib (compatibility version 11.0.0, current version 11.11.0)
	@rpath/libmpi.40.dylib (compatibility version 81.0.0, current version 81.7.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 2100.43.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)