Remove examples, headers, and docs using cpp_bindgen
#1821
Conversation
| TODO: Remove? Or are the instructions still valid for using cpp_bindgen separately? | ||
|
|
There was a problem hiding this comment.
Whether or not this file should be removed is I think my main question. Some of it still applies since the text talks about fetch-contenting cpp_bindgen. However, the headers from gridtools that use cpp_bindgen are removed with this PR, so that part is definitely not going to work.
Do the nanobind headers completely replace all the cpp_bindgen functionality, or not fully?
There was a problem hiding this comment.
Good question. Not sure what's the best option. Maybe we leave this documentation here and also keep the headers for backwards-compatibility.
nanobind just does Python <-> C++ bindings, cpp_bindgen just does Fortran <-> C++ bindings. So for GT4Py use-case cpp_bindgen is not relevant, but in case someone has a Fortran <-> C++ use-case, I would go with cpp_bindgen.
There was a problem hiding this comment.
Sounds good to me. Would you keep the fortran_array_view.hpp and fortran_array_adapter.hpp headers where they are, but without any guarantees (they'll likely bitrot if all the tests that use them are removed; but it might not matter if gridtools isn't going to have many changes anymore)?
There was a problem hiding this comment.
Yes, not perfect. I would move the testing to cpp_bindgen (if there would be a use-case)...
|
I see there's a full |
|
cscs-ci run |
This removes the `cpp_bindgen` tests and examples from gridtools. If `cpp_bindgen` will be used with gridtools storages, we should recover the tests, possibly in the `cpp_bindgen` repo.
2 participants
This removes the
cpp_bindgentests and examples from gridtools.If
cpp_bindgenwill be used with gridtools storages, we should recover the tests, possibly in thecpp_bindgenrepo.