In this thread I have described how I solved my problem (ffi bindings are difficult to create) by creating a wrapper library around freetype (simpler to create ffi bindings):
But to be silly and quote myself:
So this topic is mostly me asking for tips: What can I do to (relatively) easy, create builds for my library and package that as a racket package?
I already have gotten the impression from a few racketeers that it isn't necessarily fun to build the various platform dependent packages. Any insights into what is difficult or what tools could be used would be appreciated.
I already looked a little bit into @bogdan's libsqlite3 package. It seems it uses github actions and for aarch64 it uses self-hosted runners, is that because there aren't github provided runners for that architecture?
I guess for a start I could try to just use what is available out of the box and if there is interest for more architectures then they can be extended in some way or another.
But in general I am interest to hear about different ways this problem is being solved, by different people that maintain platform specific builds.
I'm interested in this question as well, as I am considering making a Racket package to access CPU performance counters on Linux. Unfortunately, glibc doesn't provide an API for this, so my plan is to create my own library in C to handle the low-level details. I'd like to include this lib as part of my final Racket package. Is that accepted practice? To include a pre-built shared object as part of a Racket package?
Yes, I am and that is an option as well, but I wasn't sure how portable it would be. I figured I could account for portability on the C side and provide a consistent interface to Racket code. I haven't written the code yet, so maybe portability isn't as much of a problem as I thought.