search

openmopac / mopac

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

Align OpenMP linking w/ BLAS #74

Closed godotalgorithm closed 2 years ago

godotalgorithm commented 2 years ago

This PR is intended to fix #73 by aligning how OpenMP is linked with CMake's find_package functionality, with an override path for the Mac packaging, which is not able to use find_package successfully right now because of CMake limitations.

Status

codecov-commenter commented 2 years ago

Codecov Report

Merging #74 (5000be2) into main (f10d4d9) will decrease coverage by 0.00%. The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #74      +/-   ##
==========================================
- Coverage   68.23%   68.23%   -0.01%     
==========================================
  Files         330      330              
  Lines       71706    71696      -10     
==========================================
- Hits        48932    48925       -7     
+ Misses      22774    22771       -3
Impacted Files Coverage Δ
src/run_mopac.F90 78.04% <ø> (-0.21%) :arrow_down:
src/input/wrtkey.F90 64.13% <100.00%> (+0.09%) :arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update f10d4d9...5000be2. Read the comment docs.

godotalgorithm commented 2 years ago

The source of confusion in the build system was CMake's find_package/find_library system, in conjunction with a version of libiomp5.so on the Linux GHA Runner that is a symbolic link to a (possibly non-portable) system library rather than Intel's redistributable library and appeared earlier in the search sequence. This confusion does not seem to cause problems for local builds, but it is the source of the portability problems here, and my only easy recourse is to avoid using find_package when building the Linux installer.