Re: [CMake] Centos8 FindICU problems
That works for me, but is this a documented thing anywhere? On 10/22/19 4:22 PM, Roger Leigh wrote: On 22/10/2019 21:51, Kent Williams wrote: find_package(ICU REQUIRED) It reports failure to find ICU, and I can't work out what I'm supposed to do: CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Failed to find all ICU components (missing: ICU_LIBRARY) (found version "60.2") Call Stack (most recent call first): /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake/Modules/FindICU.cmake:317 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:3 (find_package) Any suggestions? Hi Kent, You need to specify the ICU libraries you want to link with as COMPONENTS. E.g. find_package(ICU REQUIRED COMPONENTS data i18n io tu) If you don't specify any components, then it won't find any libraries at all and that will cause the check to fail which caused the above error. Regards, Roger -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Centos8 FindICU problems
On 23/10/2019 14:43, Kent Williams wrote: That works for me, but is this a documented thing anywhere? On 10/22/19 4:22 PM, Roger Leigh wrote: On 22/10/2019 21:51, Kent Williams wrote: find_package(ICU REQUIRED) It reports failure to find ICU, and I can't work out what I'm supposed to do: CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Failed to find all ICU components (missing: ICU_LIBRARY) (found version "60.2") Call Stack (most recent call first): /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake/Modules/FindICU.cmake:317 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:3 (find_package) Any suggestions? Hi Kent, You need to specify the ICU libraries you want to link with as COMPONENTS. E.g. find_package(ICU REQUIRED COMPONENTS data i18n io tu) If you don't specify any components, then it won't find any libraries at all and that will cause the check to fail which caused the above error. Regards, Roger Hi Kent, The components are all listed in the documentation: https://cmake.org/cmake/help/v3.16/module/FindICU.html It doesn't directly say that you have to have at least one component, but since ICU is a collection of libraries it's implied that you need to specify the libraries you want. Not specifying any doesn't make sense since it's going to find nothing, and that's why it fails. Regards, Roger -- 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: https://cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, master, updated. v3.16.0-rc2-116-g490da0bd33
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 490da0bd337f33c51884d7fe3bd5ac042ac0b0c5 (commit) from 44b5f037e66e58cb4b5f9877b568bc40b9b576ca (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=490da0bd337f33c51884d7fe3bd5ac042ac0b0c5 commit 490da0bd337f33c51884d7fe3bd5ac042ac0b0c5 Author: Kitware Robot AuthorDate: Thu Oct 24 00:01:04 2019 -0400 Commit: Kitware Robot CommitDate: Thu Oct 24 00:01:04 2019 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 3332ba2f60..1c8e050c59 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,7 +1,7 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 16) -set(CMake_VERSION_PATCH 20191023) +set(CMake_VERSION_PATCH 20191024) #set(CMake_VERSION_RC 0) set(CMake_VERSION_IS_DIRTY 0) --- Summary of changes: Source/CMakeVersion.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[cmake-developers] These two generator expressions should be equivalent, but one working while the other not working. Bug?
Hi Brad: The two generator expressions $<$:-pthread> and $<$,$>:-pthread> are supposed to be equivalent according to the cmake-generator-expressions manual. Up to now I have always used the first form when setting the INTERFACE_LINK_OPTIONS property of an interface library which my D examples link with. All my tests of that form for both the test_d and plplot cases work fine. So I was about to declare that my D language support (a fork of the cmake-d project which I hope to merge back with that project) was perfect for our needs (at least on Linux) until I ran into a problem with the above second generator expression which I will now describe. Some old versions (e.g., 3.13.2) of CMake that PLplot still needs to support do not implement the $ generator expression so after the first form passed all tests, I tried switching to the second generator expression for the plplot case. However, that generated errors at CMake time which are typically (for each of our D examples) CMake Error at examples/d/CMakeLists.txt:119 (target_link_libraries): Error evaluating generator expression: $ Expression did not evaluate to a known generator expression [...] -- Generating done CMake Generate step failed. Build files cannot be regenerated correctly. These errors were obtained with cmake version 3.15.20190829-g3ec986c (the version I have recently been using for testing). This is a really peculiar result since both forms provide the same information (language and compiler id) and are supposed to be equivalent, i.e., both forms should either work or not work. And the second form works for the Fortran case (where I am having to deal with a similar -pthread issue). So my guess is there is some internal implementation issue with the second form that makes it not quite equivalent to the first form, and some minor issue with my D language support (that otherwise works perfectly for PLplot needs on Linux) has exposed this implementation difference. If you confirm that guess, then ideally the CMake implementation should be changed so the second form is equivalent to the first form in all circumstances. And I would be happy to test that change with my present CMake D language support. I also need the second form of generator expression to work with older unfixed CMake versions so once you spot the implementation difference between the two forms I would also appreciate a hint about how to change my CMake D language support so the present CMake code does not generate the above type of errors for the second form of the generator expression. In case you need details about my present CMake D language support, those can be found at either cmake/test_d/cmake/Modules or cmake/modules/language_support/cmake-d_fork/ within the plplot source tree. That source tree can be cloned using git clone https://git.code.sf.net/p/plplot/plplot plplot.git Alan __ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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: https://cmake.org/mailman/listinfo/cmake-developers
