Comments (26)
I'm going with
set(_omp_enabled_for_enabled_lang OFF)
if(DEFINED CMAKE_C_COMPILER_ID)
if(OPENMP_FOUND OR OpenMP_C_FOUND)
set(_omp_enabled_for_enabled_lang ON)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS}")
endif()
endif()
if(DEFINED CMAKE_CXX_COMPILER_ID)
if(OPENMP_FOUND OR OpenMP_CXX_FOUND)
set(_omp_enabled_for_enabled_lang ON)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
endif()
endif()
if(DEFINED CMAKE_Fortran_COMPILER_ID)
if(OPENMP_FOUND OR OpenMP_Fortran_FOUND)
set(_omp_enabled_for_enabled_lang ON)
set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} ${OpenMP_Fortran_FLAGS}")
endif()
endif()
if(${_omp_enabled_for_enabled_lang})
add_definitions(-DHAVE_OPENMP)
endif()
from autocmake.
Thanks Lori! I will try to reproduce this.
from autocmake.
I believe there is a problem but at this moment cannot reproduce it with CMake 3.9.6 and GNU 8.1.0. I probably use a different compiler. Using which compilers do you observe this?
from autocmake.
I'm on cmake 3.9.4 and gcc 7.2.0 (from conda). conda gfortran isn't providing omp_lib
header or module, so that's probably why kitware findopenmp is failing to detect for Fortran, which starts the cascade.
from autocmake.
OK thanks. It would be nice if we could query OpenMP_<lang>_FOUND
but these were only introduced in 3.9.
from autocmake.
We could for each language check whether either OpenMP_<lang>_FOUND
or OpenMP_FOUND
. Also the add_definitions(-DHAVE_OPENMP)
seems kind of ugly from the modern CMake perspective. What is your opinion @robertodr?
from autocmake.
Yes, I was just going to ask if there'd be forseeable trouble with if(${OPENMP_FOUND} OR ${OpenMP_C_FOUND})
per-language? I don't know what cmake wants in the way of quotes these days.
from autocmake.
I expect no trouble. Not sure what to do with the add_definitions
but independently of it the current problem could be solved with:
if(DEFINED CMAKE_C_COMPILER_ID)
if(OPENMP_FOUND OR OPENMP_C_FOUND)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS}")
endif()
endif()
# etc. for the other languages
On the other hand the "proper" way for 3.9 and above is actually this:
https://github.com/bast/cmake-recipes/blob/master/chapter-03/recipe-05/cxx-example/CMakeLists.txt
from autocmake.
The add_definitions
should stay as-is, I think. @bast did copying the modern FindOpenMP.cmake
module work for OpenMP detection? I think that would actually be the most reasonable choice...
from autocmake.
You mean shipping the latest FindOpenMP.cmake
with autocmake and checking that it works also with 2.8? Just to make sure I understand the question.
from autocmake.
I'll experiment with those lines, thanks.
I'm a huge fan of the imported target in general. But I don't dare do it here b/c of the problem I was discussing with @robertodr about needing to suppress lgomp
linking for GCC+MKL (this is also the problem that led to the nasty table here. So basically I want the flags out of FindOpenMP but not the link libs.
from autocmake.
You can still get the flags out from the new module (though that might be on its way to deprecation)
from autocmake.
By as-is on the definitions, you mean set when C found, @robertodr? Or potentially added three times if all langs enabled?
from autocmake.
Gee, what a mess! No we definitely don't want that, so I guess either they spill over to the client:
if(OpenMP_FOUND)
target_compile_definitions(<target-name>
PUBLIC
HAVE_OPENMP
)
endif()
# or a generator expression
target_compile_definitions(<target-name>
PUBLIC
"$<$<BOOL:${OPENMP_FOUND}>:HAVE_OPENMP>"
)
or it spills over to the compiler flags:
set(CXX_FLAGS ${OpenMP_CXX_FLAGS} -DHAVE_OPENMP)
quite ugly in both cases, but I'd rather prefer the former: explicit is better than implicit (of sorts) and you get to choose the name of the preprocessor definition!
@bast, yes that's what I meant. I recall it didn't work out for FindMPI.cmake
. (This thread is moving very fast, I'm losing half of the comments 😸 )
from autocmake.
Definitely more compact.
from autocmake.
Well, 7 lines where there used to be 1. But I don't see another dumb way around it (classifying your sol'ns as "smart" cmake uses).
from autocmake.
Don't know it mine was "smart". Yours is compact wrt spilling variables over to other CMake files.
from autocmake.
For more compactness we can add a foreach looping over the languages. I think we should rename this module to omp-flags since it's really only about flags. I will test backwards compatibility of recent find module and sleep on this issue and then tomorrow comment more and/or send a PR based on our findings.
from autocmake.
Using latest FindOpenMP.cmake with older versions of CMake does not work. Already 3.5 chokes on it.
from autocmake.
Don't consider Psi4 as a an impediment to bumping min supported cmake version.
For one, all the repos have their own copies of the autocmake file. For second, someday when need is pressing and the blas/omp detection landscape is cleaner, I'll probably bump the p4 ecosystem to 3.9 or whereever all the Intel/OMP/MPI goodies are. conda is distributing 3.11 now, so access not a problem.
from autocmake.
We (the editorial we :-) are not super sure yet which minimum we want to support (#243) but until we settle that, probably as far back as 2.8 and mostly because of more conservative codes than Psi4. I will send a PR and let you both review it and we go from there.
from autocmake.
FYI, cmake 3.11 (but not 3.9) gets around my initial problem by letting you specify a subset of the enabled langs to search for find_package(OpenMP COMPONENTS C CXX)
and thus still merit the overall OpenMP_FOUND
.
from autocmake.
3.10 is the exact introduction date of the components mentioned above.
fyi, libraries returned in the OpenMP::OpenMP_CXX
target for gcc
are gomp;pthreads
and for icpc
are iomp5;pthreads
, along with corresponding lang-specific COMPILE_FLAGS
Properties for TARGET OpenMP::OpenMP_CXX:
OpenMP::OpenMP_CXX.INTERFACE_COMPILE_OPTIONS = "$<$<COMPILE_LANGUAGE:CXX>:-fopenmp>"
OpenMP::OpenMP_CXX.INTERFACE_LINK_LIBRARIES = "/home/psilocaluser/toolchainconda/envs/p4dev36/x86_64-conda_cos6-linux-gnu/sysroot/lib/libgomp.so;/home/psilocaluser/toolchainconda/envs/p4dev36/x86_64-conda_cos6-linux-gnu/sysroot/usr/lib/libpthread.so"
and all that can be copied into a new target via
include(CMakePrintHelpers)
if(TARGET OpenMP::OpenMP_CXX)
add_library(omp_cxx INTERFACE)
get_property(_ill TARGET OpenMP::OpenMP_CXX PROPERTY INTERFACE_LINK_LIBRARIES)
get_property(_ico TARGET OpenMP::OpenMP_CXX PROPERTY INTERFACE_COMPILE_OPTIONS)
set_property(TARGET omp_cxx PROPERTY INTERFACE_COMPILE_OPTIONS "${_ico}")
set_property(TARGET omp_cxx PROPERTY INTERFACE_LINK_LIBRARIES "${_ill}")
cmake_print_properties(TARGETS OpenMP::OpenMP_CXX omp_cxx
PROPERTIES INTERFACE_COMPILE_DEFINITIONS INTERFACE_COMPILE_OPTIONS INTERFACE_COMPILE_FEATURES INTERFACE_INCLUDE_DIRS INTERFACE_LINK_LIBRARIES)
message("FL: ${OpenMP_CXX_FLAGS}")
message("LN: ${OpenMP_CXX_LIB_NAMES}")
message("LI: ${OpenMP_CXX_LIBRARY}")
message("LS: ${OpenMP_CXX_LIBRARIES}")
# FL: -fopenmp
# LN: gomp;pthread
# LI:
# LS: /home/psilocaluser/toolchainconda/envs/p4dev36/x86_64-conda_cos6-linux-gnu/sysroot/lib/libgomp.so;/home/psilocaluser/toolchainconda/envs/p4dev36/x86_64-conda_cos6-linux-gnu/sysroot/usr/lib/libpthread.so
endif()
from autocmake.
Thank you for the information! I will revise #248.
from autocmake.
I pinged you on psi4/psi4#1031 and would be glad of any comments on that new OpenMP-finding scheme. Most everything is centered in https://github.com/loriab/psi4/tree/openblas/external/common/lapack . The FindTargetOpenMP.cmake file within is most relevant to this autocmake issue. It finds an OpenMP target with modern cmake or constructs one to compensate in old cmake. I know autocmake doesn't deal much with targets, but the usual variables can just read off the target. Also the psi one is CXX only, so extensions would need be be made for other langs.
from autocmake.
Thanks! I will look at it. Also I will finally restart work on this issue hopefully today.
from autocmake.
Related Issues (20)
- Make it simpler to place modules to the "standard library".
- [Discussion] Versioning strategy HOT 1
- [Discussion] move this repo to another org HOT 4
- Discover math libraries: show MKL and ScaLAPACK
- Offer option to specify project version in YAML file
- DeprecationWarning: URLopener style of invoking requests is deprecated HOT 1
- Drop Python 2 support in the update machinery HOT 1
- CMAKE_BINARY_DIR vs PROJECT_BINARY_DIR HOT 2
- Restore CI
- GNU blas/lapack integer64 detection HOT 2
- Remove boost module and tests
- Improve the way we figure out whether `cmake` command is available
- Make setup to print out wrong keyword(s)
- How to launch autocmake tests ? HOT 1
- tests failed... HOT 1
- missing "pure" python HOT 2
- python script error after running update.py HOT 1
- setup not showing the default python interpeter HOT 1
- [question] LAPACK and BLAS linking using `modules/math_libs.cmake` HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from autocmake.