PR c-koi/gmic-qt#172 is correct in that it is no longer possible
to build without -Dgmic_core, due to G'MIC-Qt relying in
now-private implementation details of G'MIC; namely, the extensions
made in gmic.cpp to CImg.
However, the solution chosen has significant shortcomings:
1. It blindly assumes that the consumed library has been built by a
GCC-compatible compiler. This is easily inferred from the lack of
symbol exports in {CImg,gmic}.{h,cpp}.
2. It makes no provision for the exported library type; G'MIC can be
built statically or dynamically.
3. In Windows, when built with MSVC, the kind of symbol export that
gmic_core implies is only available with a static libgmic.
To fix this, this commit augments G'MIC-Qt's `ENABLE_DYNAMIC_LINKING`
handling with target detection code for the above described cases.
In the case where a compatible library is not found, a fallback is
specified that will build libgmic as a separate target, then make
G'MIC-Qt link against it in order to mimic the requirements. If a
suitable system library is found, we augment it with the gmic.cpp
plugin to make the symbols visible at compile time.
This improves the appearance of the preview image for all image modes.
Color management will only be used if the 8bf plug-in host provides the
image color profile to its 8bf plug-ins.
G'MIC-Qt will attempt to retrieve the color profile for the display
that G'MIC-Qt is using when the first call to applyColorProfile is
made, if that is unsuccessful the color profile of the primary display
will be used.
The display color profile will not be refreshed if the user moves the
G'MIC-Qt UI to a different display within the same session.
Depending on the image, the 32-bit float mode may still have color
differences versus Photoshop's native rendering.
I am not sure if my code is missing a step in the color correction
process, or if it is a difference in behavior between Little CMS and
Adobe's color management engine.
I avoided the cleaner solution using IMPORTED_TARGET since it is only available in CMake 3.6+ and we were targeting 3.1. But it turns out target_link_directories used in the verbose solution requires even newer CMake 3.13.
Hardcoding `pkg-config` will work only for native builds. If you want to
cross-compile, you need to search for the appropriate tools, which is
what FindPkgConfig module does. Then you can use PKG_CONFIG_EXECUTABLE
variable which will be set according to your toolchain rules.
Also old-style binary config tools, such as gimptool, are not a good
idea as they are not very cross-compilation friendly (to do it right, we
would have to generate variants per (host, target) couple). Instead
pkg-config is the right process as it works well without having to run
non-native binaries. I am actually considering removing gimptool from
GIMP eventually (and document the generic pkg-config process instead).
Running `gimptool-2.0 --libs-noui` and `--cflags-noui` is the
equivalent to run `pkg-config --libs` (`--cflags` respectively) on
`gimp-2.0`. So let's just replace by these commands.
Sébastien Fourey
Lily Foster
L. E. Segovia
Ștefan Talpalaru
Nicholas Hayes
Marcus Rückert
Andreas Schneider
David Tschumperle
David Tschumperlé
Jan Tojnar
Sébastien Fourey
Jehan