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
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
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
--
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
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
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
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
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15193
==
Reported By:Yichao Yu
Assigned To:
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
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
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
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
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
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
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
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
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15194
==
Reported By:stopiccot
Assigned To:
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
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
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)
+
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
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
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
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:
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),
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
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
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
28 matches
Mail list logo
