Why are binaries being distributed in the repository?

[KaruroChori]

The odin bindings in this repository are distributing a very high number of binaries. This is bad on multiple levels:

• Binaries cannot be easily tracked in git, which means the size of this repository grows a lot each time they are recompiled even for minor changes. Since this repository it is meant to be used as a CMake dependency, this affects its usability greatly.
• Binaries are not easily readable by humans, so it would be easy for them to integrate malicious code inside and go undiscovered.

If binaries really must be distributed, it would be better to split them in their own repository, so that it only affects their users.

Incidently, I would also suggest cutting down on the number of fonts distributed. All examples could just use one or two instead of having one copy each. File links can be used in git repositories.

[nicbarker]

Hello, there are a couple of reasons we include binaries in the repo 🙂

• It means that for bindings (see Odin for an example) the user doesn't need the toolchain required to compile clay on their own machine, the bindings just "work" out of the box.
• Often the bindings aren't kept in exact lockstep with the main clay.h file, and so recompiling them may actually break the bindings - I intentionally don't recompile and submit these binaries until I've confirmed they work. So the binaries in the repo may not be the binaries that are produced as a result of build scripts.

I'm not sure I agree from the perspective of distributing malicious code - any code that you clone from someone's repository and run on your host machine carries that risk, unless you exhaustively review every line of code yourself (including the dependencies)

Since this repository it is meant to be used as a CMake dependency, this affects its usability greatly.

That's actually not the intention here - Clay itself is just a single file. The examples are provided for educational purposes and have CMakeLists files associated with them to make them easier to build for people who use CMake, but the actual library itself doesn't rely on CMake at all. If you're after a direct link to just the latest main clay.h from the repository, you can use https://raw.githubusercontent.com/nicbarker/clay/refs/heads/main/clay.h

It's also worth mentioning that there are now CMake options to disable pulling the code from the examples if you're concerned about size:
#216

[KaruroChori]

My mistake, I assumed you were planning some distribution in view of the latest changes to the build script. Plenty of "single file libraries" are distributed so that they can integrate with build systems like CMake or meson, but from what I understand that was not your objective.

Malicious code is much easier to detect compared to malicious binaries, I don't really see how this is arguable.
Well, as long as someone is looking for that. I agree that a full chain of trust is unpractical, but between that and distributing binaries, which are hard to perfectly reproduce, there is a good chunk of gray area :). The point is minimizing risks within capabilities, not nullifying them entirely.

Still, I now get how you are using the repository and which priorities are in place. I cannot say I like this approach to be honest, but my question was answered :D.