It should not be required to load dynamic libraries that
are not already in standard paths with these builds and
loading libraries from the static-compat prefix should be
avoided.
The warning is about invalid memory usage within the loop in
case `strSize` is zero. It is supposedly not correct because
then the loop would never be entered anyways in that case.
However, it is likely nevertheless a good idea to silence the
warning.
* Avoid forcefully setting cache variables; use a normal variable
instead
* Use the imported target generated from the pkg-config which hopefully
works better than using the variables directly
* Avoid warning when the find module was used; this is the case for
vcpkg and there the provided CppUnit library is good enough
Otherwise the wrapper might depend on `libgcc` or `libstdc++` on builds
that link against these libraries otherwise statically. Not sure why this
is only an issue on 32-bit builds. (The different exeption handling can
only explain `libgcc` but not `libstdc++`.)
* Avoid mentioning setting for library suffix as this most likely does not
need manual tweaking anymore anyways
* Add a few additional remarks
* Use a simpler example for CMake presets and document special presets only
in a further section
* Mention how to build on Windows via MSYS2 mingw64 (and not *only* via
MSVC which is definitely more complicated)
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
Martchus