The UCRT environment is a successor to the MINGW environment on Windows
with a more modern C runtime library.
Building under UCRT we get this error:
../../gimp/plug-ins/file-raw/file-darktable.c:420:7: error:
function '__p__environ' is initialized like a variable"
To fix this we use the relevant part of patch 6 from:
https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-gimp
This is untested on my side, because the bug only happens on native
builds with meson (our CI has cross-builds with meson and native builds
with autotools and I only do cross-builds locally) but I think/hope it
will work.
Basically we were using .full_path() because these rc files were also
used as input of some configure_file() calls which doesn't like custom
target objects as input (it wants strings or file objects). Yet a bug
in meson didn't like the colon used in native Windows full paths ('C:'
and such) when used in windows.compile_resources(). This has been fixed
by Luca Bacci in: https://github.com/mesonbuild/meson/pull/9368
Yet we just cannot depend on very early meson (or worse dev meson code).
On the other hand, if the input is a custom_tgt object, it uses the
object ID which we give as first parameter of custom_target() so we know
it's appropriately named without colons (such as 'gimp_plugins_rc').
Thus we should not bump into this issue again.
For the few usage in configure_file(), I just add a .full_path() only
when needed at call time.
Last but not least, I replace the bogus `meson --version` call by a
`python3 -c 'exit()'` as advised by Eli Schwartz:
2afa019c70 (note_1284951)
The reason is that it is apparently possible (or will be when some
reimplementation of meson will be done) that the `meson` executable
itself does not exist. On the other hand, `python3` should always be
there, as a mandatory dependency of the build tool.
In order to use an appropriate `python3`, I made the
pythonmod.find_installation() check required in our build (which should
not be a problem since it's a meson requirement as well), even when the
-Dpython option is false (this one depends on other requirements too
anyway, such as version and pygobject). This way I can call this meson
variable of discovered python in my bogus call, instead of calling a
(potentially different) python from PATH environment.
The Lua API is undergoing changes in darktable master. I've fixed the lua-scripts repository as I've made
changes, but I forgot about the collateral damage.
Attached is a fixed version of file-darktable-export-on-exit.lua which should be good for darktable 3.6 and
beyond.
Fixes#6421
darktable GUI is "mangled" when opened from GIMP for a reporter. There
was already some debug info outputted (when running with DARKTABLE_DEBUG
environment variable). Adding the environment list (and some separation
titles to make it easier to distinguish what is what). Hopefully it will
help debugging.
See #6195 and https://github.com/darktable-org/darktable/issues/7402
This gives a big cleanup in the meson.build files of the plug-ins.
It's also quite a bit more maintainable, since anything that changes in
libgimp's dependencies, linkage, ... doesn't have to be copy-pasted into
each plug-in.
And by "supporting CR3", I mean sending the file over to raw developer
software which are supposed to support it! At the very least RawTherapee
support CR3 (since recent version 5.8 apparently), not sure about
darktable (but if not yet, I assume it won't be long either).
and in an attack of madness, changes almost all file plug-in
code to use GFile instead of filenames, which means passing
the GFile down to the bottom and get its filename at the very
end where it's actually needed.
It's an ancient concept from ancient times when we didn't have URIs
and only filenames (not to speak of GFile), and actually even from
before the ancient time before that ancient time when we first had
ones and zeros, and only had zeros.
It's just too weird to be public. Remove its properties from the wire
protocol and from pluginrc. Instead, have all GParamSpecs' flags on
the wire and in pluginrc, so we can use stuff like
GIMP_PARAM_NO_VALIDATE.
Port the remaining few places to GIMP_PROC_ARG_STRING().
I'm sure something is broken now wrt UTF-8 validation,
will add tighter checks in the next commit.
... provided by RawTherapee's installer (version 5.5+).
See https://github.com/Beep6581/RawTherapee/issues/4783.
This patch required a small change to file_raw_get_executable_path
because the RawTherapee installer is supposed to work without admin
privileges and therefore can't write to HKLM.
Reviewer's note (Jehan): RawTherapee's installer does not add the
registry entry yet. We assume the upstream bug report will end up doing
so (someone has to make the first step!). :-)
When cross-compiling, I got various linking errors for printf() calls:
> undefined reference to `libintl_printf'
I am unsure why, since this is not recent code, and it used to build
fine with mingw64 compilers (last I cross-built, which is many months
ago). Anyway g_printf() works fine, all necessary libs are already
linked, and it is supposed to be a synonym. So let's just go the easy
way and use g_printf() only.
(cherry picked from commit c49afa4f84)
I am going to forbid plug-ins from being installed directly in the root
of the plug-ins/ directory. They will have to be installed in a
subdirectory named the same as the entry point binary.
This may seem useless for our core plug-ins which are nearly all
self-contained in single binaries, but this is actually a necessary
restriction to eliminate totally the DLL hell issue on Windows. Moving
core plug-ins in subfolders is only a necessary consequence for it.
I just cross-compiled for Windows after a long time. The header file is
all lowercase on a cross-compilation MinGW-w64 environment. I'm not sure
what is the case on Windows, but since this platform is case-insensitive
for file names, I believe this won't break anything on native builds.
I realize that on Fedora 27, the output of `darktable --version` is:
"this is darktable darktable-2.2.5-4.fc27"
This is different from the expected output in our plug-in ("this is
darktable 2.2.5"). I assume this version string can be customized and
distribution packagers will use the capability. So a regular expression,
in a slightly more flexible fashion would be better. I still assume that
the version string with start with "this is darktable", but then I
accept any non-number string until I reach a common major.minor.patch
version-looking string.
otherwise, implicit transitive linking will pull in the installed
libs, not the ones from the source tree, and the build can fail when
any of the libs' APIs changes.
Also remove some useless #includes.
Apparently Lua chokes when it sees c:\darktable\... as a path to a script,
thinking the '\d' was an escape sequence. Thus we have to add an extra
layer of escaping. Houdini like. Who came up with the brilliant idea to
use '\' as a separator anyway? So much pain just to be different?
Otherwise people will install older versions and won't understand why
the plug-ins won't work. It's just a little annoying that these version
strings have to be hardcoded this way. We could add macros in a header,
but that would be only half a solution. Ideally we'd rather have some
discovery logics at some point.
Hopefully it works, since that's untested (I have no MacOS access). This
is mostly code from file-darktable.c, made generic and factorized into
file-raw-utils.[ch]. At least it still builds and work fine on Linux.
I used the CFBundleIdentifier from `tools/osx/Info.plist.in` in
RawTherapee code. I didn't add a Win32 registry key base though, since I
couldn't find any relevant data for this in RawTherapee code.
...with known plugins
Add new plug-in file-raw-placeholder.c that registers itself for
loading all RAW formats from file-raw/file-formats.h, but does nothing
except returning an error message pointing to darktable and
RawTherapee.
When no real RAW loader is installed, this plug-in is selected
automatically as RAW loader, otherwise the first installed RAW loader
is used. Selecting another in prefs still works as before.
Jacob Boerema