Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Minor changes:
Run CI for pushes to any branch, not just master. This is mostly relevant for forks, where you will often want CI on WIP branches. Releases still check that they are on the master branch and won't be generated for other branches.
The GCC
stringop-overflow
heuristic still seems to be buggy, tripping in seemingly irrelevant areas, and in different areas depending on toolchain/OS. Hence, just disable it for now; conforms with legacy behavior.Fix a macro redefinition in the GTK CMake code
Add a missing "included" source to the desktop-ui CMake code so it shows up in IDEs
gersemi
formatting passLastly:
Allow generating DWARF symbols in MSYS2/MinGW environments. This is controlled by the cache variable
ARES_MINGW_USE_DWARF_SYMBOLS
(on by default only for GCC, inoperable under MSVC/Clang-CL). This allows for easier use of gdb or lldb for debugging on Windows. The support here is considered incomplete but functional for debugging the main ares executable.In particular, we do not generate DWARF symbols on Windows in ares-deps, so debugging dynamic dependency issues with gdb or lldb will require self-compiling dependencies. DWARF symbols are also embedded and this PR does not ship them with releases. The "primary" Windows clang build will continue to use CodeView symbols so that releases may be debugged with WinDbg, Visual Studio, etc.
I am not satisfied with this level of support, but I am also not sure whether "full support" for two independent debugging symbol formats on one platform is a reasonable thing or a good idea to maintain. For one thing, ares-deps targets the MSVC ABI for portability, where DWARF symbol availability is limited. Targeting the GNU ABI in ares-deps would mean reconciling multiple independent components' dependence on libc++ that would eventually need to be linked together. This might theoretically be possible but in any case is not undertaken here. Also not undertaken is the extant PDB functionality for stripping into separate files, bundling, copying to the rundir, etc.