Re: [cmake-developers] FindMPI take 2
Hi Brad,
0001-correctly-detect-MPI-linker-flags-for-Intel-MPI-mayb.patch
Thanks. That adds a block much like one above it. Can the preceding
block be modified to match both -Wl, and -Xlinker? Something like:
-string(REGEX MATCHALL (^| )-Wl,([^\ ]+|\[^\]+\)
MPI_ALL_LINK_FLAGS ${MPI_LINK_CMDLINE})
+string(REGEX MATCHALL (^| )(-Wl,|-Xlinker )([^\ ]+|\[^\]+\)
MPI_ALL_LINK_FLAGS ${MPI_LINK_CMDLINE})
may work (untested).
Indeed the merging of the two sections is the elegant decision... I
kept it in two separate blocks maybe due to my phobia for debugging
regexes.
I have attached a checked patch for linker. flags with the blocks merged.
The check for whether the CMAKE_LANG_COMPILER is already a MPI
compiler requires a try_compile. Is there some other way to check
to see if there is any chance before the full test?
I do not know the answer to this. When I did my changes I tried to
minimise them.
Also I'm not sure we fully support using a MPI compiler as the main
compiler. I can't think of anything that definitely won't work, but
we don't have nightly testing for the case.
Generally I've viewed the MPI compiler interrogation to be much like
using pkg-config or $pkg-config tools to get the info needed to use
a package. Once that is done then MPI should be treated like any
other library.
Unfortunately MPI wrapper is abused as main compiler in some projects.
Practically my patch just checks for that. As it involves a pretty
active decision from the user, I think we shall be fine.
The user should be able to specify MPI_lang_COMPILER explicitly.
Perhaps it could be initialized by ENV{MPICC}, ENV{MPICXX}, and
ENV{MPIFC} environment variables? This selection is much like
picking the primary compiler in the first place.
This will the the best situation but will involve changes to the
FindMPI module that may be above my station to do.
regards,
Alin
From 9a8b2c7e0e39bef0e3aad84c8f1ba7e3489ab262 Mon Sep 17 00:00:00 2001
From: Alin Marin Elena alinm.el...@gmail.com
Date: Thu, 11 Dec 2014 09:56:39 +
Subject: [PATCH 2/2] Linking flags correctly detected for intel compilers
---
Modules/FindMPI.cmake | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/Modules/FindMPI.cmake b/Modules/FindMPI.cmake
index 5f23c02..840b714 100644
--- a/Modules/FindMPI.cmake
+++ b/Modules/FindMPI.cmake
@@ -363,18 +363,7 @@ function (interrogate_mpi_compiler lang try_libs)
endif()
# Extract linker flags from the link command line
-string(REGEX MATCHALL (^| )-Wl,([^\ ]+|\[^\]+\) MPI_ALL_LINK_FLAGS ${MPI_LINK_CMDLINE})
-set(MPI_LINK_FLAGS_WORK)
-foreach(FLAG ${MPI_ALL_LINK_FLAGS})
- if (MPI_LINK_FLAGS_WORK)
-set(MPI_LINK_FLAGS_WORK ${MPI_LINK_FLAGS_WORK} ${FLAG})
- else()
-set(MPI_LINK_FLAGS_WORK ${FLAG})
- endif()
-endforeach()
-
-# Extract linker flags from the link command line Intel compilers.. others maybe
-string(REGEX MATCHALL (^| )-Xlinker ([^\ ]+|\[^\]+\) MPI_ALL_LINK_FLAGS ${MPI_LINK_CMDLINE})
+string(REGEX MATCHALL (^| )(-Wl,|-Xlinker )([^\ ]+|\[^\]+\) MPI_ALL_LINK_FLAGS ${MPI_LINK_CMDLINE})
set(MPI_LINK_FLAGS_WORK)
foreach(FLAG ${MPI_ALL_LINK_FLAGS})
if (MPI_LINK_FLAGS_WORK)
--
2.2.0
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindMPI take 2
Hi Kelly
I have been looking into this. For my setup, I found it useful to compare
the CMAKE_LANG_COMPILER to the list of known mpi wrapper names and prepend
_MPI_${lang}_COMPILER_NAMES with CMAKE_LANG_COMPILER so that the remaining
logic in FindMPI.cmake chooses the user supplied compiler/mpi-wrapper over
any of the other choices. Something like this:
# append vendor-specific compilers to the list if we either don't know the
compiler id,
# or if we know it matches the regular compiler.
foreach (lang C CXX Fortran)
foreach (id GNU Intel PGI XL)
if (NOT CMAKE_${lang}_COMPILER_ID OR CMAKE_${lang}_COMPILER_ID STREQUAL
id)
list(APPEND _MPI_${lang}_COMPILER_NAMES
${_MPI_${id}_${lang}_COMPILER_NAMES})
endif()
unset(_MPI_${id}_${lang}_COMPILER_NAMES)# clean up the namespace here
endforeach()
+ # If cmake_$lang_compiler matches a known mpi compiler wrapper name,
+ # prefer the provided value.
+ get_filename_component( compiler_wo_path ${CMAKE_${lang}_COMPILER} NAME )
+ set( ${lang}_compiler_is_mpiwrapper false )
+ foreach( mpiwrapper ${_MPI_${lang}_COMPILER_NAMES} )
+if( ${mpiwrapper} STREQUAL ${compiler_wo_path} )
+ set( ${lang}_compiler_is_mpiwrapper true )
+endif()
+ endforeach()
+ if( ${lang}_compiler_is_mpiwrapper )
+list( REMOVE_ITEM _MPI_${lang}_COMPILER_NAMES ${compiler_wo_path} )
+list( INSERT _MPI_${lang}_COMPILER_NAMES 0 ${compiler_wo_path} )
+ endif()
endforeach()
checked your patch and indeed works.
In addition to that I have noticed that in the interrogate function we
never check that we can actually generate a binary with the findings,
shall we have a try_mpi_compile at the end of interrogate function?
regards
Alin
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015299]: CMakeExpandImportedTargets does not support generator expression TARGET_PROPERTY w/o target specified
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15299 == Reported By:Paweł Stankowski Assigned To: == Project:CMake Issue ID: 15299 Category: Modules Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2014-12-11 06:36 EST Last Modified: 2014-12-11 06:36 EST == Summary:CMakeExpandImportedTargets does not support generator expression TARGET_PROPERTY w/o target specified Description: CMakeExpandImportedTarget expands target names to file paths including targets from IMPORTED_LINK_INTERFACE_LIBRARIES* properties of expanded targets. However, IMPORTED_LINK_INTERFACE_LIBRARIES property may contain generator expression $TARGET_PROPERTY:prop. It should be converted to $TARGET_PROPERTY:target,prop expression. Otherwise following error will appear: $TARGET_PROPERTY:prop may only be used with targets. It may not be used with add_custom_command. Specify the target to read a property from using the $TARGET_PROPERTY:tgt,prop signature instead. BTW: INTERFACE_LINK_LIBRARIES property should be preferred, IMPORTED_LINK_INTERFACE_LIBRARIES should not be used when the former is defined. Currently INTERFACE_LINK_LIBRARIES property is ignored. Steps to Reproduce: This is easily reproducible on Windows with Qt libraries. For example, Qt5 adds following generator expression in IMPORTED_LINK_INTERFACE_LIBRARIES of Qt targets: $$AND:$STREQUAL:$TARGET_PROPERTY:TYPE,EXECUTABLE,$BOOL:$TARGET_PROPERTY:WIN32_EXECUTABLE,$NOT:$BOOL:$TARGET_PROPERTY:Qt5_NO_LINK_QTMAIN,$TARGET_POLICY:CMP0020:Qt5::WinMain;C:/Qt5/5.3/msvc2013_opengl/bin/Qt5Networkd.dll;C:/Qt5/5.3/msvc2013_opengl/bin/Qt5Cored.dll;$$AND:$STREQUAL:$TARGET_PROPERTY:TYPE,EXECUTABLE,$BOOL:$TARGET_PROPERTY:WIN32_EXECUTABLE,$NOT:$BOOL:$TARGET_PROPERTY:Qt5_NO_LINK_QTMAIN,$TARGET_POLICY:CMP0020:Qt5::WinMain Qt4 does similar thing. == Issue History Date ModifiedUsername FieldChange == 2014-12-11 06:36 Paweł StankowskiNew Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] VS, WINCE: Fix entry point for Unicode builds
I think that would be the best approach. If you work on it, please ensure the implementation supports all Windows toolchains on all generators, or at least those combinations that already support WIN32_EXECUTABLE. I had a look trough the code. I found that the VS6 generator also sets the entry point for Windows CE (https://github.com/Kitware/CMake/blob/a11dda1c4883eddf763ba1eb2979b45220886b01/Source/cmLocalVisualStudio7Generator.cxx#L1313) But here it is set to wmain as default if Unicode is active. So for consistency reason I think the VS10 generator should do the same. This is also consistent with the case for Windows NT where the entry point is not set by CMake and wmain is automatically selected by VS if UNICODE is enabled This should be in addition to a WIN32_ENTRYPOINT property that the user can set to override the default. Pascal -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindMPI take 2
Alin Elena wrote: In addition to that I have noticed that in the interrogate function we never check that we can actually generate a binary with the findings, shall we have a try_mpi_compile at the end of interrogate function? In general, I think this is a good idea because I have encountered situation were the cmake compiler was a different flavor (intel, gnu, pgi, etc) than the selected mpi compiler wrapper. However, if the chosen mpi compiler wrapper is the same as CMAKE_LANG_COMPILER, we don't need the try_compile because cmake will have already verified that the CMAKE_LANG_COMPILER works. -kt -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindMPI take 2
Hi KT, In general, I think this is a good idea because I have encountered situation were the cmake compiler was a different flavor (intel, gnu, pgi, etc) than the selected mpi compiler wrapper. However, if the chosen mpi compiler wrapper is the same as CMAKE_LANG_COMPILER, we don't need the try_compile because cmake will have already verified that the CMAKE_LANG_COMPILER works. The nornal test will not test any MPI feature...to be sure that actually the wrapper is an MPI compiler we will need to test a MPI test. Also we need to add a test to see if the found mpi has mpi.mod and can be used. This is a Fortran usage only. Also I like Brad's suggestion on MPICCfriends. regards, Alin -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] OpenBSD and srand()/rand() changes
Yes, setting an explicit seed should make subsequent calls to random be deterministic... On Wed, Dec 10, 2014 at 9:50 AM, Rolf Eike Beer e...@sf-mail.de wrote: Am 10.12.2014 15:38, schrieb Ben Boeckel: Hi, It appears[1] as though OpenBSD has changed srand and rand which we use in CMake for string(RANDOM) and with the change, RANDOM_SEED will be a no-op there. Do we want to use rand_deterministic and srand_determinitic or does it not matter? From what I see there we want to use the deterministic variants. May also get us rid of some warnings on OpenBSD. Eike -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [DISCUSSION] Using COMPONENTs for CMake install(...)?
Konstantin Podsvirov wrote: The data now includes subfolders Help, Modules and Templates. Why are Help (the rst set of files)? As they are used after installation? Yes. The Help files need to be mandatory too. They are used by cmake for showing documentation on the command line like cmake --help-command file There are a series of resources that have not been specified. Please look at the files in the folder: http://ifw.podsvirov.pro/cmake/dev/unspecified/ What components to include these files? Everything in share seems to be about '3rd party integration'. For example, files with different licenses? Probably the same component as the Copyright.txt file. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
