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.

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.

PR c-koi#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.

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.

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.

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.

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.