Closed ntBre closed 1 year ago
Merging #156 (836a838) into main (842293e) will not change coverage. The diff coverage is
n/a
.
:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@ Coverage Diff @@
## main #156 +/- ##
=======================================
Coverage 66.68% 66.68%
=======================================
Files 331 331
Lines 73720 73720
=======================================
Hits 49157 49157
Misses 24563 24563
That got the CI to pass, but I think the WIN32 check might still need to be
if(WIN32 AND CMAKE_Fortran_COMPILER_ID STREQUAL "Intel")
or even a more complicated sequence of conditionals, depending on the supported compilers. As far as I can tell, gfortran on Windows uses -g like Mac and Linux, but I don't have any Windows machines to test on. From a quick search, PGI and Flang also support the -g option, so this might take care of all the compilers I found in CMakeLists.txt.
I'm a little confused about what environment this is trying to target. -DCMAKE_BUILD_TYPE=Debug
should already be adding appropriate debug flags to compilers recognized by CMake. I haven't needed to do anything beyond this to use gdb
. Could you post an explanation of the specific problem that you are having as a GitHub Issue, possibly with some snippet from the CMake output and what compiler flags are actually being used when you run make VERBOSE=1
after the makefile is set up?
This is a reminder to me that I should probably request that PRs to fix specific problems first articulate the problem that they intend to fix as a GitHub Issue first.
Okay, sorry for the premature PR. I will make a full reproduction and submit an issue with the relevant information.
No problem, I recently learned from an experience contributing to PySCF that submitting a GitHub Issue first is a good habit. I submitted several Issues, and it was conceivable that one of the PySCF developers could have fixed it promptly themselves. It turned out that I was able to fix it myself in a timely manner, and it was then that I filed a PR to fix and close the Issue.
Welp, sorry about that. I don't know what I was doing before, but I must have been very confused about cmake. I cloned a fresh copy of the repo to prepare the issue and rebuilt with CMAKE_BUILD_TYPE=Debug and gdb found the debug symbols immediately. It even worked when I went back to Release (which had no symbols as expected) and back to Debug. Apologies again and thanks for the advice.
I feel like I must have missed the existing way to do this, but I wanted to step through the code in gdb and couldn't figure out another way to get debug symbols.