[cmake-developers] Improving the version selection behavior of EXACT
find_package(foo 2.0 EXACT) means EXACT, i.e. only 2.0 is allowed. In most cases this behavior is not the one that one would expect or need. Most people would instead allow any 2.0.x version to match. This sort of selection is currently impossible without additional effort in every Find*.cmake that is used. I came over this when I tried converting FindLua5[01].cmake to use FindLua.cmake, but I can't do find_package(Lua 5.0 EXACT) in there because e.g. 5.0.1 would not be accepted then, and I neither can do find_package(Lua 5.0) because that may return e.g. 5.2 instead. Since we can't change this because of the usual backward compatibility concerns I think we should introduce a new version mode, e.g. EXACT_OR_MINOR (or any other naming you find more appropiate). In case this is aggreed on I would try to create a patch ASAP to be able to still land it in 3.1. Opinions? Eike signature.asc Description: This is a digitally signed message part. -- 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] Improving the version selection behavior of EXACT
How about IN_RANGE and/or IN_SET options? Where IN_RANGE takes two version numbers (low and high) and does the equivalent of: if ( (NOT ver VERSION_LESS low) AND (ver VERSION_LESS high) ) Or possibly even IN_RANGES with multiple ranges... And IN_SET takes a list of explicit version numbers and looks for exact matches among multiple choices...? It's all pie in the sky until you reach up and pull one down. ;-) D On Fri, Oct 3, 2014 at 3:35 AM, Rolf Eike Beer e...@sf-mail.de wrote: find_package(foo 2.0 EXACT) means EXACT, i.e. only 2.0 is allowed. In most cases this behavior is not the one that one would expect or need. Most people would instead allow any 2.0.x version to match. This sort of selection is currently impossible without additional effort in every Find*.cmake that is used. I came over this when I tried converting FindLua5[01].cmake to use FindLua.cmake, but I can't do find_package(Lua 5.0 EXACT) in there because e.g. 5.0.1 would not be accepted then, and I neither can do find_package(Lua 5.0) because that may return e.g. 5.2 instead. Since we can't change this because of the usual backward compatibility concerns I think we should introduce a new version mode, e.g. EXACT_OR_MINOR (or any other naming you find more appropiate). In case this is aggreed on I would try to create a patch ASAP to be able to still land it in 3.1. Opinions? 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
[cmake-developers] Preparing for CMake 3.1.0-rc1
Hi Folks, In preparation for the first 3.1 release candidate I will feature- freeze master as of 2014-10-09. As of now there are several open topics in 'next' that we should try to land in master by then, but please refrain from adding non-trivial changes in the meantime. Thanks, -Brad -- 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] Improving the version selection behavior of EXACT
On 10/03/2014 03:35 AM, Rolf Eike Beer wrote: find_package(foo 2.0 EXACT) means EXACT, i.e. only 2.0 is allowed. In most cases this behavior is not the one that one would expect or need. Most people would instead allow any 2.0.x version to match. Yes. The EXACT should refer to exactly matching whatever components are given by the caller. Following components should still be free to vary. If the caller wants them to be exact too then they should be specified. This sort of selection is currently impossible without additional effort in every Find*.cmake that is used. Is that because of FPHSA's implementation? Since we can't change this because of the usual backward compatibility concerns I think we should introduce a new version mode, e.g. EXACT_OR_MINOR (or any other naming you find more appropiate). In case this is aggreed on I would try to create a patch ASAP to be able to still land it in 3.1. I'd rather not introduce a new API in an important command like find_package immediately before a release. However, the documentation of find_package has always said that it is up to the Find module (or package version file in Config mode) for each package to decide whether a version matches. I think FPHSA could be changed to implement the expected behavior for EXACT discussed above. The current implementation effectively adds unlimited implicit .0.0.0 to the caller's components as part of if(VERSION_EQUAL). Instead FPHSA could truncate the available version to match the number of components provided by the caller's version request before using if(VERSION_EQUAL). -Brad -- 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] Improving the version selection behavior of EXACT
Am Freitag, 3. Oktober 2014, 08:41:47 schrieb Brad King: On 10/03/2014 03:35 AM, Rolf Eike Beer wrote: find_package(foo 2.0 EXACT) means EXACT, i.e. only 2.0 is allowed. In most cases this behavior is not the one that one would expect or need. Most people would instead allow any 2.0.x version to match. Yes. The EXACT should refer to exactly matching whatever components are given by the caller. Following components should still be free to vary. If the caller wants them to be exact too then they should be specified. This sort of selection is currently impossible without additional effort in every Find*.cmake that is used. Is that because of FPHSA's implementation? I think that is the main reason. Since we can't change this because of the usual backward compatibility concerns I think we should introduce a new version mode, e.g. EXACT_OR_MINOR (or any other naming you find more appropiate). In case this is aggreed on I would try to create a patch ASAP to be able to still land it in 3.1. I'd rather not introduce a new API in an important command like find_package immediately before a release. However, the documentation of find_package has always said that it is up to the Find module (or package version file in Config mode) for each package to decide whether a version matches. I think FPHSA could be changed to implement the expected behavior for EXACT discussed above. The current implementation effectively adds unlimited implicit .0.0.0 to the caller's components as part of if(VERSION_EQUAL). Instead FPHSA could truncate the available version to match the number of components provided by the caller's version request before using if(VERSION_EQUAL). If it is acceptable to change FPHSA in that way I can just go for it. Eike signature.asc Description: This is a digitally signed message part. -- 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] Improving the version selection behavior of EXACT
On 10/03/2014 08:43 AM, Rolf Eike Beer wrote: I think FPHSA could be changed to implement the expected behavior for EXACT If it is acceptable to change FPHSA in that way I can just go for it. Yes, please try it. Thanks, -Brad -- 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] Ninja: Use 'console' pool for CMake re-run if possible
On 10/02/2014 06:08 PM, Matthew Woehlke wrote: I haven't tried it yet, but I've been wanting this feature; thanks for the patch! I tried the patch and it works well. When ninja reruns CMake one can now see the output immediately. Please see also http://public.kitware.com/Bug/view.php?id=14915 which it sounds like this (partly) fixes; you may want to reference that in your patch or vice versa. I've applied the patch here and added the issue reference: Ninja: Use 'console' pool for CMake re-run if possible (#14915) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9f32a241 (The partly is that the request is also for the 'install' target to use the console pool; not sure if you did that, want to tackle that, etc., but in any case this is a step in the right direction.) I'll leave that to a follow-up patch if anyone wants to do it. Thanks, -Brad -- 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 0015193]: Error when one of the parent directory is a symlink to it's parent directory
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15193 == Reported By:Yichao Yu Assigned To: == Project:CMake Issue ID: 15193 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2014-10-03 09:01 EDT Last Modified: 2014-10-03 09:01 EDT == Summary:Error when one of the parent directory is a symlink to it's parent directory Description: If one of the parent directory of the source directory is a symlink to one of its parent directory, cmake fails at configure time on add_subdirectory. Directory structure to reproduce this: ``` % tree . ├── 1 │ ├── 2 │ │ └── cmake │ │ ├── a │ │ │ └── CMakeLists.txt │ │ └── CMakeLists.txt │ └── 4 - . └── 3 - 1 6 directories, 2 files ``` The higher level `CMakeLists.txt` is ``` % cat 1/2/cmake/CMakeLists.txt project(cmake-test) cmake_minimum_required(VERSION 2.8) add_subdirectory(a) ``` and the lower level `CMakeLists.txt` is empty. When trying to build in `1/4/2/cmake/build` ``` % cmake .. -- The C compiler identification is GNU 4.9.1 -- The CXX compiler identification is GNU 4.9.1 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake Error at CMakeLists.txt:3 (add_subdirectory): add_subdirectory not given a binary directory but the given source directory /home/yuyichao/tmp/cmake-test/1/4/4/4/2/cmake/a is not a subdirectory of /home/yuyichao/tmp/cmake-test/1/4/4/2/cmake. When specifying an out-of-tree source a binary directory must be explicitly specified. -- Configuring incomplete, errors occurred! See also /home/yuyichao/tmp/cmake-test/1/4/2/cmake/build/CMakeFiles/CMakeOutput.log. ``` Another real life example can be found in the comment here[1] and the qtcurve issue here[2]. [1] http://kde-look.org/content/show.php?content=40492 [2] https://github.com/QtCurve/qtcurve/issues/77 == Issue History Date ModifiedUsername FieldChange == 2014-10-03 09:01 Yichao Yu New 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] Integrate fixdep for kconfig
On 10/02/2014 08:52 AM, Sam H. wrote: I try my best to describe my understanding. Thanks for the explanation. My prototype patch is try to do what fixdep do in CMake. It is do-able in the CMake Makefile generator but AFAICT cannot possibly work for the Ninja generator or the VS/Xcode generators. Those all let the build tool do their own dependencies. 4. Do more configuration: $ cd .. $ make menuconfig $ make silentoldconfig In plain CMake, configuration like this is normally kept in CMake cache variables and edited with ccmake or cmake-gui. It's not the same interface as menuconfig but it has the same capabilities and works on all platforms CMake supports. Because the license issue and mmap() issue, codes need to be re-implement. Yes. The implementor also shouldn't look at the original source. However, I'm not familiar with CMake codes and C++. So what can I do if this feature could be accepted? Personally I see little value in supporting an auxiliary configuration system in a way that works only with one of our generators. However, if it can be implemented in a way that is not intrusive and can be enabled optionally then it would be an acceptable patch. There must still be a way to follow autoconf.h with normal scanning if the kconfig part is not enabled. -Brad -- 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] Extracting target metadata, IDE integration
On Thu, Oct 2, 2014 at 2:43 PM, Brad King brad.k...@kitware.com wrote: On 10/01/2014 07:46 PM, Aleix Pol wrote: I'm very interested in getting this in and iterating forward. Any comments? How do changes get integrated? My main concern is that the format has not been proven with a corresponding implementation of an actual IDE/plugin to use it. Once we start producing a format changing it later will be problematic for compatibility. Even though we added a version number to the file, an IDE might not be updated along with a CMake that produces a newer version. Perhaps rather than a boolean CMAKE_EXPORT_IDE_METADATA setting to enable this, the value should be a version number. That way enabling it requires explicit specification of which format version is desired. In this case we would need to use a format version number that is independent of th CMake version number. It would simply be incremented every time changes are made. If the version number has the form major.minor then we could increment the minor number whenever fields are added and the major number whenever fields are removed or changed. -Brad Ok, I can start working on it in a KDevelop branch and see what needs to be changed. Regarding passing the version rather than ON probably makes sense. I'll work on a patch to make it work this way. Aleix -- 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] Extracting target metadata, IDE integration
Brad King wrote: On 10/01/2014 07:46 PM, Aleix Pol wrote: I'm very interested in getting this in and iterating forward. Any comments? How do changes get integrated? My main concern is that the format has not been proven with a corresponding implementation of an actual IDE/plugin to use it. Once we start producing a format changing it later will be problematic for compatibility. Even though we added a version number to the file, an IDE might not be updated along with a CMake that produces a newer version. This probably needs a way to query for the IDE which versions the given CMake version supports, no? Otherwise a newer IDE may request version 3 and just get nothing because the CMake binary only supports 1 and 2. Eike -- signature.asc Description: This is a digitally signed message part. -- 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] CMake, Ninja generator, and ExternalProjects
On 2014-07-25 17:05, Williams, Norman K wrote: There’s also the ‘console pool’ facility that would allow ExternalProject builds to display output, though that would get back to the Gmake issue of different processes interleaving output. It wouldn't; the 'console' pool only permits one job at a time. So your outer build would run serially, directly showing the output of whatever (*one*) inner build is running at the time. -- Matthew -- 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] Ninja: Use 'console' pool for CMake re-run if possible
On 2014-10-03 08:56, Brad King wrote: On 10/02/2014 06:08 PM, Matthew Woehlke wrote: Please see also http://public.kitware.com/Bug/view.php?id=14915 which it sounds like this (partly) fixes; you may want to reference that in your patch or vice versa. I've applied the patch here and added the issue reference: Ninja: Use 'console' pool for CMake re-run if possible (#14915) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9f32a241 (The partly is that the request is also for the 'install' target to use the console pool; not sure if you did that, want to tackle that, etc., but in any case this is a step in the right direction.) I'll leave that to a follow-up patch if anyone wants to do it. I was sort-of hoping / encouraging that Sylvain might be interested :-). Anyway, thanks! (Re-running CMake is the more important task, I think, as that's known to take minutes in some cases... install, while also an obvious candidate for such treatment, I believe tends to be quicker, so it less important.) -- Matthew -- 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] Improving the version selection behavior of EXACT
Brad King wrote:
On 10/03/2014 08:43 AM, Rolf Eike Beer wrote:
I think FPHSA could be changed to implement the expected behavior for
EXACT
If it is acceptable to change FPHSA in that way I can just go for it.
Yes, please try it.
It looks like this line is the culprit:
if (NOT ${${_NAME}_FIND_VERSION} VERSION_EQUAL ${VERSION})
I can solve this in CMake language, but the question is again if it may be
worth solving in the command itself? Meanwhile I'll prepare an implementation
in CMake code, we can replace that with anything better anytime later.
Eike
--
signature.asc
Description: This is a digitally signed message part.
--
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] Improving the version selection behavior of EXACT
On 10/03/2014 11:53 AM, Rolf Eike Beer wrote:
It looks like this line is the culprit:
if (NOT ${${_NAME}_FIND_VERSION} VERSION_EQUAL ${VERSION})
I can solve this in CMake language, but the question is again if it may be
worth solving in the command itself? Meanwhile I'll prepare an implementation
in CMake code, we can replace that with anything better anytime later.
Yes, I think the command should be fixed to compare only as many
components as are given on both sides, ignoring extra on one side.
However, that will require a policy.
Please fix it in the module by hand for now and look at adding a
policy for this after the 3.1 release.
Thanks,
-Brad
--
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] Improving the version selection behavior of EXACT
Brad King wrote:
On 10/03/2014 11:53 AM, Rolf Eike Beer wrote:
It looks like this line is the culprit:
if (NOT ${${_NAME}_FIND_VERSION} VERSION_EQUAL ${VERSION})
I can solve this in CMake language, but the question is again if it may be
worth solving in the command itself? Meanwhile I'll prepare an
implementation in CMake code, we can replace that with anything better
anytime later.
Yes, I think the command should be fixed to compare only as many
components as are given on both sides, ignoring extra on one side.
However, that will require a policy.
Please fix it in the module by hand for now and look at adding a
policy for this after the 3.1 release.
Yes, that was my plan. This is what I have now (diff -b for easier review):
diff --git a/Modules/FindPackageHandleStandardArgs.cmake
b/Modules/FindPackageHandleStandardArgs.cmake
index e8d1dfb..f8c990e 100644
--- a/Modules/FindPackageHandleStandardArgs.cmake
+++ b/Modules/FindPackageHandleStandardArgs.cmake
@@ -290,12 +290,38 @@ function(FIND_PACKAGE_HANDLE_STANDARD_ARGS _NAME
_FIRST_ARG)
if(VERSION)
if(${_NAME}_FIND_VERSION_EXACT) # exact version required
+# count the dots in the version string
+string(REGEX REPLACE [^.] _VERSION_DOTS ${VERSION})
+# add one dot because there is one dot more than there are components
+string(LENGTH ${_VERSION_DOTS}. _VERSION_DOTS)
+if (_VERSION_DOTS GREATER ${_NAME}_FIND_VERSION_COUNT)
+ # give an exact match if the first ${NAME}_FIND_VERSION_COUNT
components of the version string match
+ # this constructs the equivalent of
(([^.]\\.){${${_NAME}_FIND_VERSION_COUNT}})
+ unset(_VERSION_REGEX)
+ # foreach(RANGE) doesn't like it if stop is greater start
+ if (${${_NAME}_FIND_VERSION_COUNT} GREATER 1)
+foreach (_NUM RANGE 2 ${${_NAME}_FIND_VERSION_COUNT})
+ set(_VERSION_REGEX ${_VERSION_REGEX}[^.]*\\.)
+endforeach ()
+ endif ()
+ string(REGEX REPLACE ^(${_VERSION_REGEX}[^.]*)\\..* \\1
_VERSION_HEAD ${VERSION})
+ unset(_VERSION_REGEX)
+ if (NOT ${_NAME}_FIND_VERSION VERSION_EQUAL _VERSION_HEAD)
+set(VERSION_MSG Found unsuitable version \${VERSION}\, but
required is exact version \${${_NAME}_FIND_VERSION}\)
+set(VERSION_OK FALSE)
+ else ()
+set(VERSION_MSG (found suitable exact version \${VERSION}\))
+ endif ()
+ unset(_VERSION_HEAD)
+else ()
if (NOT ${${_NAME}_FIND_VERSION} VERSION_EQUAL ${VERSION})
set(VERSION_MSG Found unsuitable version \${VERSION}\, but
required is exact version \${${_NAME}_FIND_VERSION}\)
set(VERSION_OK FALSE)
else ()
set(VERSION_MSG (found suitable exact version \${VERSION}\))
endif ()
+endif ()
+unset(_VERSION_DOTS)
else() # minimum version specified:
if (${${_NAME}_FIND_VERSION} VERSION_GREATER ${VERSION})
Eike
--
signature.asc
Description: This is a digitally signed message part.
--
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 0015194]: Bug in CMake Xcode generator
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15194 == Reported By:stopiccot Assigned To: == Project:CMake Issue ID: 15194 Category: CMake Reproducibility:always Severity: minor Priority: high Status: new == Date Submitted: 2014-10-03 13:34 EDT Last Modified: 2014-10-03 13:34 EDT == Summary:Bug in CMake Xcode generator Description: Generated project Xcode fails to build libraries with only object input files. Test repo: https://github.com/stopiccot/cmake_xcode_bug Xcode fails to create output file for output_library_bugged target nevertheless reporting that build succeeded. Everything is fine for output_library_fixed target. This actually maybe an Xcode not a CMake bug but we should consider adding this workaround into CMake. Example of real world project that suffers from this issue - https://github.com/PixarAnimationStudios/OpenSubdiv. == Issue History Date ModifiedUsername FieldChange == 2014-10-03 13:34 stopiccot New 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] Preparing for CMake 3.1.0-rc1
On Fri, Oct 03, 2014 at 08:27:56 -0400, Brad King wrote: In preparation for the first 3.1 release candidate I will feature- freeze master as of 2014-10-09. As of now there are several open topics in 'next' that we should try to land in master by then, but please refrain from adding non-trivial changes in the meantime. I've just added the ubsan-support branch to stage (not merged yet; no new tests). It contains some documentation updates for AddressSanitizer and MEMORYCHECK_TYPE which were missed as well as support for MemoryCheckSanitizerOptions which adds key/value values to the environment variables for the sanitizers (ASAN_OPTIONS, TSAN_OPTIONS, and UBSAN_OPTIONS). Feel free to cherry-pick the documentation fixes (or I can spin out a branch) if the other changes are too late (I hope to add tests Monday, but can do it today if that's too late). --Ben -- 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] Ninja: Use 'console' pool for CMake re-run if possible
Le 03/10/2014 17:41, Matthew Woehlke a écrit : On 2014-10-03 08:56, Brad King wrote: I'll leave that to a follow-up patch if anyone wants to do it. I was sort-of hoping / encouraging that Sylvain might be interested :-). I quickly checked if it is possible. Unlike the rerun target which is manually added by the Ninja generator, the install and package targets are handled in a generic way by the utility target generator. Thus, handling these targets is not as straightforward as rerun. I'll keep digging a bit, maybe I can find a way to do it. ;-) -- 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] Improving the version selection behavior of EXACT
On 10/03/2014 12:47 PM, Rolf Eike Beer wrote:
+ # give an exact match if the first ${NAME}_FIND_VERSION_COUNT
components of the version string match
+ # this constructs the equivalent of
(([^.]\\.){${${_NAME}_FIND_VERSION_COUNT}})
+ unset(_VERSION_REGEX)
+ # foreach(RANGE) doesn't like it if stop is greater start
+ if (${${_NAME}_FIND_VERSION_COUNT} GREATER 1)
+foreach (_NUM RANGE 2 ${${_NAME}_FIND_VERSION_COUNT})
+ set(_VERSION_REGEX ${_VERSION_REGEX}[^.]*\\.)
+endforeach ()
+ endif ()
Since _FIND_VERSION_COUNT is always [0-4], I think a hand-coded lookup
table may be simpler and faster.
+ string(REGEX REPLACE ^(${_VERSION_REGEX}[^.]*)\\..* \\1
_VERSION_HEAD ${VERSION})
Perhaps use something like
if(VERSION MATCHES ^(${_VERSION_REGEX}[^.]*)\\..*)
set(_VERSION_HEAD ${CMAKE_MATCH_1})
else()
message(... bad VERSION in call to fphsa...)
endif()
in case something fails to match for some reason.
Thanks,
-Brad
--
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] Ninja: Use 'console' pool for CMake re-run if possible
On 2014-10-03 14:00, Sylvain Joubert wrote: Le 03/10/2014 17:41, Matthew Woehlke a écrit : On 2014-10-03 08:56, Brad King wrote: I'll leave that to a follow-up patch if anyone wants to do it. I was sort-of hoping / encouraging that Sylvain might be interested :-). I quickly checked if it is possible. Unlike the rerun target which is manually added by the Ninja generator, the install and package targets are handled in a generic way by the utility target generator. Thus, handling these targets is not as straightforward as rerun. I'll keep digging a bit, maybe I can find a way to do it. ;-) Many thanks, Sylvain. Don't worry if it's going to be a pain; I was thinking since you were in there anyway it might be easier for you. It's certainly much appreciated if you want to tackle this, but no worries if you don't. Thanks again for the re-run CMake patch! -- Matthew -- 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] Improving the version selection behavior of EXACT
Am Freitag, 3. Oktober 2014, 14:34:38 schrieb Brad King:
On 10/03/2014 12:47 PM, Rolf Eike Beer wrote:
+ # give an exact match if the first ${NAME}_FIND_VERSION_COUNT
components of the version string match + # this constructs the
equivalent of (([^.]\\.){${${_NAME}_FIND_VERSION_COUNT}}) +
unset(_VERSION_REGEX)
+ # foreach(RANGE) doesn't like it if stop is greater start
+ if (${${_NAME}_FIND_VERSION_COUNT} GREATER 1)
+foreach (_NUM RANGE 2 ${${_NAME}_FIND_VERSION_COUNT})
+ set(_VERSION_REGEX ${_VERSION_REGEX}[^.]*\\.)
+endforeach ()
+ endif ()
Since _FIND_VERSION_COUNT is always [0-4], I think a hand-coded lookup
table may be simpler and faster.
Yes.
+ string(REGEX REPLACE ^(${_VERSION_REGEX}[^.]*)\\..* \\1
_VERSION_HEAD ${VERSION})
Perhaps use something like
if(VERSION MATCHES ^(${_VERSION_REGEX}[^.]*)\\..*)
set(_VERSION_HEAD ${CMAKE_MATCH_1})
else()
message(... bad VERSION in call to fphsa...)
endif()
in case something fails to match for some reason.
I counted the number of dots before, so there must be a match.
Eike
signature.asc
Description: This is a digitally signed message part.
--
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] fix-OSX-bundle-rpaths-and-Qt5 topic
On 09/30/2014 01:44 PM, Adam Strzelecki wrote:
Please merge the topic to 'next' for testing when you're ready.
We can at least see if the dashboard stays clean with it.
Done.
Since this was merged the dashboard has reported several failing
instances of the BundleUtilities test. They have errors like:
/usr/bin/find: invalid mode '+0111'
CMake Error at .../Modules/BundleUtilities.cmake:395 (string):
string sub-command REPLACE requires at least four arguments.
Please extend the topic with a fix. Also use quoting like:
- string(REPLACE \n ; file_list ${file_list})
+ string(REPLACE \n ; file_list ${file_list})
to make sure the command runs when the file list is empty.
After extending the topic please merge to 'next' again and
check if it fixes the dashboard.
Thanks,
-Brad
--
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] FindThreads-macro topic
Eike, The topic adds a macro to FindThreads: +macro(check_threads_lib LIBNAME FUNCNAME VARNAME) Since it is not meant for public use, please name it something like _threads_check_lib. Thanks, -Brad -- 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] kwsys SystemTools::RelativePath()
On 09/30/2014 10:05 AM, Nils Gladitz wrote: When both operands are the same absolute path I get the empty string as a result. Should it be .? Perhaps. One would need to track down existing call sites to see where that might affect behavior. IIRC it is exposed through file(RELATIVE_PATH), so it may need a policy. That is probably overkill because there are legitimate use cases where an empty string looks better than .. -Brad -- 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] kwsys SystemTools::RelativePath()
On 03.10.2014 21:13, Brad King wrote: On 09/30/2014 10:05 AM, Nils Gladitz wrote: When both operands are the same absolute path I get the empty string as a result. Should it be .? Perhaps. One would need to track down existing call sites to see where that might affect behavior. IIRC it is exposed through file(RELATIVE_PATH), so it may need a policy. That is probably overkill because there are legitimate use cases where an empty string looks better than .. I guess that might be a matter of definition. I wouldn't consider the empty string a valid path though I understand that this may be what people expect now given that this behavior has already been established. I've worked around the issue I had with the wix-fix-root-dir-prop topic for now so there is no immediate need to change behavior before the 3.1 release. Thanks for the feedback. Nils -- 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] FindThreads-macro topic
Am Freitag, 3. Oktober 2014, 15:02:42 schrieb Brad King: Eike, The topic adds a macro to FindThreads: +macro(check_threads_lib LIBNAME FUNCNAME VARNAME) Since it is not meant for public use, please name it something like _threads_check_lib. Will do. signature.asc Description: This is a digitally signed message part. -- 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] kwsys SystemTools::RelativePath()
Is the result of RelativePath guaranteed to be a directory name, or is it possibly a file name? If a directory, then perhaps . makes sense and wouldn't negatively impact anything (other than cosmetically) if changed. But if a file, then . doesn't make as much sense. . to me implies it is the current directory or the directory containing this thing depending on the context. D On Fri, Oct 3, 2014 at 3:30 PM, Nils Gladitz nilsglad...@gmail.com wrote: On 03.10.2014 21:13, Brad King wrote: On 09/30/2014 10:05 AM, Nils Gladitz wrote: When both operands are the same absolute path I get the empty string as a result. Should it be .? Perhaps. One would need to track down existing call sites to see where that might affect behavior. IIRC it is exposed through file(RELATIVE_PATH), so it may need a policy. That is probably overkill because there are legitimate use cases where an empty string looks better than .. I guess that might be a matter of definition. I wouldn't consider the empty string a valid path though I understand that this may be what people expect now given that this behavior has already been established. I've worked around the issue I had with the wix-fix-root-dir-prop topic for now so there is no immediate need to change behavior before the 3.1 release. Thanks for the feedback. Nils -- 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
