To those purists who only want to adopt human generated code I have put df at the front of the librarys, and my apologies to Fabien (and thanks to his tolerance) for any increase in his work load . The Llama library could be interesting as it lets you see some of the confidence and other measures inside the Llm. Theres a really terrible example there of a Llm’s face .
No problem @Tonyg that’s part of a maintainers effort. But please read my comments because the name of the projects are not the only issues.
I’ll post it here so other can benefit from it:
For a binding project you have several options that are way more user friendly.
If the library is available in unix distributions. Make an “external crate” to declare this library in the alire index (e.g. with Raylib: libraylib-external.toml. And then in your crate add a dependency to this external crate: raylib-2.0.0.toml
If the C project you are binding is small enough. Instead of asking users to compile the C projects by hand., you can try to do is to compile the C code using gprbuild. This is what I did in this binding for instance: littlefs-ada In particular those two lines in littlefs.gpr
.gpr files in your projects are not “standard”, I highly recommend using the .gpr file generated by alr init and only doing small modifications when needed. Looking at ada_imgui.gpr, you have a switch that is only compatible with macOS (-Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk), and you don’t have different build modes for release vs development situations.
The build-switches configuration that you specify in your .toml will have no effect because your .gpr are not standard. See above.
In the ada_stb project, ada_stb.ads file, you have declared a crate version constant Crate_Version : constant String := "0.1.0-dev"; This is redundant with Alire’s crate configuration system which will provide this constant, and will always be in sync with the version defined in alire.toml
.