So, whipping my next rawproc version into shape, running out of version numbers, so it has to be 1.0. Accordingly, I’d like for most things to be not-so-hacky, so I’m resolving a number of things, like proper metadata (exiv2) and clean lens correction (lensfun). lensfun is a particular challenge, as they’re changing the API between 0.3.2 and 0.3.95, and guess what, some environments (msys2) have already moved to 0.3.95, alpha status notwithstanding, I guess.
So, while I build my Windows releases with mxe.cc (!!!), I build my personal version on a Surface 3 with msys2. I’m having a rather weird crash problem on it with lensfun 0.3.95, the database Load() just kills the process after a bit of spinning around, no messages whatsoever. I tried to find it with gdb, and guess what, it runs just fine there. (&^%&*&!!). Sooooo, I cloned lensfun from the github repository, branch master (what the heck), and compiled for Linux to see if the nastiness followed. Well, to my surprise, the compile failed, most of my lensfun function calls can’t find a compliant routine. Did a bit of comparison between the master and 0.3.95 docs, and gee, the 0.3.95 API is further changed in master…
Does anyone know the backstory to this? Forget the crash for a moment; I’ll try compiling lensfun in msys2, see if there is a bug in the msys2 package…
I think that times ago there was a problem with the lensfun configuration management. A new 0.3.95 version number was defined in some code and somebody in the MSYS2 team thought it was a stable release.
But those numbers have no meaning (doesn’t come from git tagging). On github, I think the last tag is 0.3.2, so 0.3.95 has no meaning regarding configuration control.
So I think it’s not a good idea to use the Lensfun MSYS2 package.
On W10/MSYS2, I build the master branch on a regular basis. I put the build somewhere (not in mingw64) and I keep old builds to be sure to be able to revert to preceding version if there is a problem.
I don’t know why , but until now, RT and ART are ok with those lensfun builds.
It’s conservative but not sure if it is the best to do.
I wrote that in rawpedia « Windows build « because it is the simplest method that works.
Perhaps somebody with insight in lensfun can recommend what to do?
edit: I am now building v0.3.95-471-g47c2ab8e
There’s a v0.3.95 tag in the repo, and 471 commits since as of today.
I just checked out 0.3.2, compiled and installed it, re-linked rawproc, and it works fine.
On another note, I’m compiling all the libraries I use past libjpeg, libtiff, and libpng, as I’m finding the distro packages aren’t as performant. rawproc was taking an long time to display after each tool update; got a lot faster when I replaced the Ubuntu package of LIttleCMS with a hand-compiled version where I made sure threading was enabled. Same thing with libraw.
But v0.3.95 was defined ten days early by modifying VERSION_MICRO in Cmakelist.txt.
The git tagging is not used inside the building of lensfun, version.h being generated with the cmakelist.txt info. I think it’s a very bad habit to do that instead of using the configuration control provided by git as it is done in RT.
Furthermore the tag 0.3.95 identifies an alpha version and not a stable version.
I have no doubt about that. It is why I wrote to use 0.3.2 in Rawpedia windows building.
But, this version is 4 years old and I think there was a lot of improvement in the code.
As you see above, I build v0.3.95-471-g47c2ab8e and it works with RT and ART.
I hope the lensfun team will issue a stable version in a near future.
If you have a list of time critical dependencies, I will try to build them on windows
I’m okay on that, when I build my release wininstallers, I use a mxe.cc toolchain. I’ll build the compilers and basic image libraries in that, but I’ll compile exiv2, littlecms, libraw, and lensfun myself with the same toolchain.
