openmopac / mopac

Molecular Orbital PACkage
http://openmopac.net
GNU Lesser General Public License v3.0
111 stars 31 forks source link

Compile with debug symbols when CMAKE_BUILD_TYPE=Debug #156

Closed ntBre closed 1 year ago

ntBre commented 1 year ago

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.

codecov-commenter commented 1 year ago

Codecov Report

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           
ntBre commented 1 year ago

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.

godotalgorithm commented 1 year ago

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.

ntBre commented 1 year ago

Okay, sorry for the premature PR. I will make a full reproduction and submit an issue with the relevant information.

godotalgorithm commented 1 year ago

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.

ntBre commented 1 year ago

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.