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
* 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.
Martchus