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
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 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] 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__COMPILER, we don't need the try_compile > because cmake will have already verified that the CMAKE__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 MPICC&friends. 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] 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__COMPILER, we don't need the try_compile because cmake will have already verified that the CMAKE__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] [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
[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 $. It should be converted to $ expression. Otherwise following error will appear: "$ 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 $ 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: $<$,EXECUTABLE>,$>,$>>,$>:Qt5::WinMain>;C:/Qt5/5.3/msvc2013_opengl/bin/Qt5Networkd.dll;C:/Qt5/5.3/msvc2013_opengl/bin/Qt5Cored.dll;$<$,EXECUTABLE>,$>,$>>,$>: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] FindMPI take 2
Hi Kelly > I have been looking into this. For my setup, I found it useful to compare > the CMAKE__COMPILER to the list of known mpi wrapper names and prepend > _MPI_${lang}_COMPILER_NAMES with CMAKE__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
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__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__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 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