This is useful as it makes consuming libraries less dependent on using the
CMake module or pkg-config file correctly. This should especially decrease
the likelihood of running into linker errors when consuming a static build
of the libraries where e.g. `CPP_UTILITIES_STATIC` needs to be defined.
* Disable workaround by default; with the CLI-wrapper available it makes no
sense to run this code unnecassarily when the main executable is invoked
* Remove check for Mintty; with the workaround disabled by default it
is no longer necassary to avoid it
* Simplify the CLI-wrapper to rely on main application for enabling UTF-8
and virtual terminal processing as it relies on it for attaching to the
parent's console anyways
Starting the console from a GUI application is not working very
well - so let's just provide a 2nd executable for the CLI. It
will be a simple console application that merely invokes the main
application passing all standard I/O. Unfortunately this does not
mean the existing hacks can be removed. Without them the wrapper
still doesn't get any I/O from the GUI application.
The config script for adding the target (which is generated
by CMake) otherwise complains that referenced dependencies
are missing. Not sure why this was never a problem. Maybe
the packages were just present anyways or CMake added
additional checks at some point.
Some backend libraries of Syncthing Tray and Reflective RapidJSON only use
certain headers of qtutilities/c++utilities. The current solution did not
really work because it did not distinguish between the build and install
interface and also did not take compile definitions and options into
account.
Rely on generator expressions to get the correct filename. This has never
worked because WINDOWS_EXT was usually only set after WindowsResources has
been included.
* Also enable the "lib" prefix which CMake would add by default again; it
has only been removed to preserve compatibility with qmake when switching
from qmake to CMake
* None of these changes are enabled by default to preserve compatibility
This basically creates imported targets from those
pkg-config modules. It also supports static linkage.
The main effort here is that those imported targets
are also exported appropriately. This is implemented
by letting the config script re-run pkg-config as
required.
Previously the case when the dependency of a static library
was provided by a dynamic library has not been handled
correctly leading to linker errors when building the final
application.
* Add include path of own header files for build
and external use via imported target. Previously
only include dirs required for external libs were
added.
* Using global include dirs is no longer required.
* When PUBLIC_SHARED_INCLUDE_DIRS is empty, adding
"${PUBLIC_SHARED_INCLUDE_DIRS}" to public include dirs
does not leave INTERFACE_INCLUDE_DIRECTORIES property
empty. Instead the source dir is added. So just don't
use quotes here.
Martchus
Hannah Rittich