let’s say it’s a very taxing platform to work with. some initial stuff seems to be working, other features i simply didn’t attempt yet (among these loading raw images…). if you know windows and msys2 and are interested, here is a github issue intended to track what’s working and what isn’t.
because it’s so rough, i’m not providing a binary build (yet). if it stabilises, i’ll probably do a github workflow to automatically build it.
nope. getting past the adware and antivirus popup windows, as well as the stock market and weather applets. also fighting over cpu resources with the microsoft bitcoin daemon or whatever is running in the background…
… and assuming for the moment you were actually interested in some technicalities ;):
the binaries compiled pretty much out of the box in msys2. the build system is very much not an issue, make works just fine (even vscode supports it, but i didn’t find out how to do anything in vscode). there were a couple of stat/scandir/gnu-isms i needed to replace. this is probably for the better long term.
one more interesting issue was how linking works on windows vs. ELF. on linux you can just -rdynamic and access symbols from the main executable in the modules directly. i do this to access global module state, the logging system, and some interface functions that connect nodes on a graph. on windows you can’t expose symbols via the linker like this (from exe->dll) but you need to explicitly grab the address. this leads to this interesting set of macros so i can run the rest of the module code unchanged. arguably this may also be a good thing (define the exposed module api explicitly).
fwiw meson is actually useful for complex stuff that is heavy on dependencies.
That is one way of doing it, but you don’t need to. More frequently (and conveniently), one just marks the API symbols for export in a cross-platform way, and on Windows links them automatically via the generated stub/import library (implib).
how do you create the import lib from the .exe though? i didn’t find a way that didn’t involve restructuring the build to make pretty much all of the executable a dso/dll.
you have no network during the build. so if you have those external git repositories as submodules. it will be fetched before the build and served into your build env.
Well as a “relaxation exercise” after/between work I am trying to make vkdt run on Arch (EndeavourOS, Manjaro etc.), but so far I wasn’t successful. Anyway the Appimage does not work on Arch/derivatives. Will post some bug reports later.
hm okay. i mean i could do the grown up thing as darktable does and do a big library. i just thought it was a fun exercise. will look into gcc visibility too, it comes with an article by the ulrich drepper
hehe didn’t i point you to this in the rawproc thread? anyways the internet connection part is the issue:
so now if i have cmake external repos (or a simple shallow git clone in my makefile) i only know which dependencies to fetch once i build, not before. so what i do now (involves an extra step which i tend to forget or do wrong) is that there’s a second git repository that contains the code and also a clone of the dependencies for a certain configuration. the OBS uses this one as the source for the packages.
vkdt can run on Manjaro, @hanatos helped me to get it working, The appimage worked also. But both only on my notebook - on my PC it didn’t: I think the difference is the graphic card on my PC, it supports vulkan not completely.
Well, you gotta put the internet connection somewhere. I haven’t gotten a software package in the mail since Borland Turbo Pascal…
I’m picking at the same sort of thing in writing a CMake build for rawproc. I want a build from just distro packages, and that’s pretty straightforward. But if one wants decent functionality out of certain libraries, they have to build:
Libraw: distros just can’t keep up with new camera incorporations, and libraw has a foundational place in a lot of distros, don’t want to confuse it with a more recent rawproc-specific build. /usr/local doesn’t cut it…
Lensfun: No environment for which I’m building is delivering > 0.3.3, and those later commits have some good cleanup and functionality.
LittleCMS: The fast-float plugin is a must.
librtprocess: The source of demosaic goodness! Not in any build environment I know of, to date…
So, with the gnarled mess that is autotools, I long ago created a build system that would let me just point to arbitrary include directories and .a library files. I would just stay with that, but it’s a bit brittle as OSs upgrade and I’m tired of telling the few that express interest that rawproc is a mess to build. So, CMake…
IMHO CMake is only a little less nuts than autotools, in that for the life of me I can’t divine its fundamental organization. At least not enough to reliably do what I described above with GNU autotools. While they tell you that you can just identify a .a library to target_library_files, It Just Doesn’t Work sometimes. And it’s in the mess of targets somewhere; I get situations where i do that for some library, and all of a sudden symbols are missing from another library. I ‘make VERBOSE=1’ to see the link command, and all is there in the right order, WTF???
I clearly don’t know enough about CMake. But my hobby is photography, not freaking CMake…
Oh, ExternalProject lets you identify a particular commit hash for a gitub-downloaded project, I think that might keep the internet connection from happening during a re-build…
i’m using this line (and similar in other modules) to do the on-demand clone:
but the problem is that the obs build machines don’t have internet. so the automated build process will fail when running into this piece of makefile. they require to download everything all at once up front…
Why is this a problem? Once you have MSYS2 installed with all the required packages, you can bundle the needed DLLs w/ your package/installer. dt does it, RT does it, GIMP does it, Inkscape does it, …
