Enabling both depending on `ENABLE_DEVEL_DEFAULTS` limits the usefulness of
`ENABLE_DEVEL_DEFAULTS` because it can then only be used of both tools are
installed (and especially `cmake-format` might not be installed). It makes
more sense to simply enable those targets depending on whether the tools
are installed or not. If they are explicitly enabled it is still a hard
error if the tools cannot be found.
Judging by the code the CMake find module actually attempts to cover this
case but it doesn't seem to work in practice - at least not when there are
only static libs and thus we find those static libs without explicitly
specifying `OPENSSL_USE_STATIC_LIBS`.
Even sub arguments (e.g. `--help`) should be treated as values to be passed
to a nested argument parser (as documented). The sub arguments are only
added in this case to appear in the help.
* 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.
It is still not perfect but now at least:
* Redirections to a file and pipes are no longer broken with `cmd.exe`
* Pipes are no longer broken in PowerShell
* It works at all when using MSVC
* The whole workaround is skipped for Mintty (as it is not needed at all)
* Sending a return key to the terminal in the end has been removed as it
caused more harm than good in certain terminals and did not work in
terminals other than `cmd.exe` anyways
* The preset must inherit from "debug" first so the build type is
not overridden
* Use the debug library of cppunit
* Avoid configuring ccache which is not generally used under
Windows
* Add helper that allows to specify the exit code (in case a non-zero
exit code is actually expected)
* Use the proper macros to inspect the status returned by `waitpid()` to
print/check the exit status correctly
When changing tagparser to actually make use of the overloads
that use sendfile64() it breaks with "Bad file descriptor". So
better disable this until it has been better tested.
There might be unexpected limitations like
https://github.com/Martchus/cpp-utilities/issues/24. To be able to at least
workaround those limitations it makes sense to allow disabling the
optimization completely.
* Wrap long lines
* Improve wording
* Mention icon bundling
* Remove obsolete notes
* List requires MSYS2 and VCPKG packages for Windows builds using CMake
preset
* Set CXX flags manually to specify the `/MT` flag explicitly; this is
needed as compilations of moc objects apparently don't pick-up the
variable `CMAKE_MSVC_RUNTIME_LIBRARY` and instead use what the Qt build
had used (which breaks the compilation when using a shared Qt build with
this setup which otherwise prefers static libraries)
* Set build type explicitly to release as otherwise a debug build would be
made (but we have `win-x64-msvc-static-debug` for that)
* Specify the VCPKG target triplet to prefer static libs
* Disable the Qt Quick GUI for now; otherwise passwordmanager is trying to
pull-in kirigami
* Remove most hardcoded paths for dependencies; with the correct VCPKG
target triplet those paths can be auto-detected (except for CppUnit)
* Move packaging info into its own section
* Link build instructions for Tag Editor as well as they differ
slightly from Syncthing Tray
* Use consistent path separator for Windows-specific variables
Using this function like this seems only be possible with `libstdc++`. The
standard lib of MSVC and Clang both don't support this (so it is not just
MSVC and thus not Windows-specific).