lopcode
Investigate automation of libvips upgrades
- GitHub Action to check for releases over at https://github.com/libvips/libvips?
- Would need to build for a particular platform (probably Linux), and then run the generation scripts
- Produce an automated PR?
If you do this, make sure to state the needed libvips version in the release. As long as the ABI version doesn't change, upgrading shouldn't be an issue.
With an ABI change though, this could become a nightmare for production updates.
Also note that you could write a bash/sh script and have it run on all three major systems. Github windows runner comes with git, including git bash, which is able to run simple bash scripts, and macos/OSX and *nix aren't an issue anyway.
I've been thinking about this - there's the version of the bindings, and the version of libvips to consider. I wonder if a combined version might make sense, like 0.5.1-vips-8.15.3? Need to check how other bindings approach the problem.
Note that I just had to build libvips manually for latest Alma Linux, as it's not available as package there. The REMI repo has it, but not in the most recent version, and I couldn't find out which ABI version corresponds to which libvips version. What I found out though is that JVips for 8.12.2 also works for libvips 8.15.3, so at least there it seems that ABI compatibility is all that matters.
It's most probably the same with FFM, because, as far as I get it, that's one of the big points of FFM: using the standard c call convention/ABI. If that's the case you could name your version according to ABI version (currently 42) and have it being compatible with a couple of libvips versions. Also, at least for macos and *nix it should easily be possible to create an sh script to check for the installed ABI version.
I added some description to the README but a specific difference with vips-ffm is it uses the bindings/operations API from libvips - I'm expecting that any VImage (or V(Prefix)) operation will work fine across minor version differences.
Maybe some stuff in VipsRaw would break, but vips-ffm intentionally only exposes what it needs to call the operations API. So I think the binary compatibility story for vips-ffm will be better 🤞
Did a little more investigation in to a module that would include native libraries, built with GitHub Actions, and it still seems pretty fragile to me - JVips for example extracts the library to a temporary directory and loads it from there.
Maybe there's a nicer way to bundle native libraries in a module, need to investigate more.
You could auto generate releases via github actions and always create 2 versions, one as on LTS with a constant libvips version, and the other with the newest one.
As for ABI compatibility, you could automatically download the headers for the lib for different versions, preprocess them (e.g. gcc -fpreprocessed -dD -E -P someheader.h, not sure this works for .h files), concat them in a sorted order, and then diff them. While this is not 100% foolproof (e.g. contents of a void* could be anything and theoretically change between versions), it should work very well with libvips.
A way easier option would probably be to post this as a question on the vips github, and they would probably be rather supportive to someone creating what basically is a language binding for Java. That's something you as the author would have to do though of course.
Did a little more investigation in to a module that would include native libraries, built with GitHub Actions, and it still seems pretty fragile to me - JVips for example extracts the library to a temporary directory and loads it from there.
Maybe there's a nicer way to bundle native libraries in a module, need to investigate more.
we do that for sqlite-jdbc, and it's a pain to build the native lib for all the platforms. It is required when using JNI, but for FFM as you can use the native libs without modification, i would advise against shipping the native lib.
