Late to the party, but you can take a look at my cross-OS library for this: GitHub - mosteo/den: Directory Enumeration for Ada
Despite the README statement, it also provides basic functions to deal with softlinks. In particular, the thick binding is in den/src/den-os.ads at 4844a1d40cf38d96f7d15b20234c237e8ad2db6e · mosteo/den · GitHub. The thin binding is in the body.
It uses another lib of mine to avoid manually dealing with the low-level buffers for the C side: GitHub - mosteo/cstrings: Convenience subprograms to interact with C strings. I’ve done some large bindings to C libraries and it gets boring fast.
About the whole ordeal of automated thin bindings and thick bindings, you might find something useful in my presentations about RCLAda, e.g. this one: ada4ros2/doc/MOSTEO-Ada-Europe-2019-slides.pdf at 696c9e1350e7ec24ce839a6f5e75fbdd46df78e8 · ada-ros/ada4ros2 · GitHub
That’s I think the largest and most complex C binding I’ve had to deal with. From the start I decided that doing it all manually was foolish, so it relies on an automatic thin binding generated as you did, and on top I manually develop the proper thick Ada binding. There was some friction at times (when the thin binding couldn’t be directly compiled by GNAT, or when it didn’t generate some complex macros), that I worked around by manually tweaking the generated files and using them as overrides in the GPR project file. Still, I had to do it only for a couple of files among scores of them, and it ceased to be a problem a few years ago.
This strategy has proven invaluable over the years, as the C spec has changed a number of times and rather than mystery crashes, I got compilation errors when my thick binding doesn’t find or matches some thin subprogram that has changed. I’ve seen other language bindings report exactly these issues in that same project.
The approach is integrated in the ROS build process, that triggers the thin binding generation, so it’s transparent for users. Nowadays, the automatic thin binding generation could be done as part of the build process of any Alire crate too (and of course with any other build tool that has hooks, unlike plain gprbuild).
This is overkill when you just need a couple C functions (e.g., in den it’s all manual, but those are long-time POSIX/Windows existing functions that shouldn’t change), but for any large project I don’t think I would do it any other way.