On 05/12/13 18:27, Matthew Woehlke wrote:
On 2013-12-05 02:36, Alan W. Irwin wrote:
Sorry, this turned out to be a false alarm. Despite which cmake
telling me I was using cmake-2.8.12.1 [snip]
...which is, of course, why you should always use type in bash
rather than which :-). type, being a
Hi Marcel,
You could use the -p option.
For example:
$ type -p ld
/usr/bin/ld
Hth
Jc
On Fri, Dec 6, 2013 at 3:28 AM, Marcel Loose lo...@astron.nl wrote:
On 05/12/13 18:27, Matthew Woehlke wrote:
On 2013-12-05 02:36, Alan W. Irwin wrote:
Sorry, this turned out to be a false alarm.
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14634
==
Reported By:Stephen Kelly
Assigned To:
On 12/05/2013 03:39 PM, Alan W. Irwin wrote:
But if you replace
message(FATAL_ERROR Should stop loop?) ==
add_subdirectory(non_existent_directory)
Okay, so the code in question is:
while(1)
add_subdirectory(non_existent_directory)
message(STATUS Did I make it by FATAL_ERROR?)
On 04/12/13 10:15, Daniele E. Domenichelli wrote:
Please review the topic ExternalProject_exclude-from-all.
I added a second part to the patch to ad an EXCLUDE_FROM_ALL argument to
ExternalProject_Add
If this is set, the all target will not depend on the external project
This might be useful
On 12/04/2013 10:41 AM, Brad King wrote:
On 12/04/2013 07:22 AM, Daniele E. Domenichelli wrote:
Done and merged to next again.
Now the ExternalProject tests fail on the continuous builds.
Please take a look.
The RunCMake.ExternalProject test failed almost everywhere last
night and still
I assume these new failures are mine, but cannot reproduce it.
http://open.cdash.org/testDetails.php?test=222455969build=3128109
http://open.cdash.org/testDetails.php?test=222466359build=3128147
I've tried on Windows 7 with MSVC 2012 and 2005, debug and release.
Can someone check why the test
On 2013-12-06 09:46-0500 Brad King wrote:
On 12/05/2013 03:39 PM, Alan W. Irwin wrote:
But if you replace
message(FATAL_ERROR Should stop loop?) ==
add_subdirectory(non_existent_directory)
Okay, so the code in question is:
while(1)
add_subdirectory(non_existent_directory)
On 05/12/13 14:56, Brad King wrote:
Without a policy project authors will not be warned about the change in
behavior that would be caused by bumping cmake_minimum_required(VERSION).
Ok, let's assume that we add a C++ implementation with a CMP policy
that does
* OLD policy = SKIP_EMPTY
*
On 2013-12-06 14:51, Daniele E. Domenichelli wrote:
Are you sure you don't want the command to be renamed to
parse_arguments? The only commands containing cmake looks strictly
related to cmake, and the arguments parsing does not look that much
related...
FWIW, I was sort-of hoping it would be.
On 12/06/2013 01:41 PM, Clinton Stimpson wrote:
I assume these new failures are mine, but cannot reproduce it.
http://open.cdash.org/testDetails.php?test=222455969build=3128109
http://open.cdash.org/testDetails.php?test=222466359build=3128147
The failure was dependent on registry content.
On Friday, December 06, 2013 03:17:44 PM Brad King wrote:
On 12/06/2013 01:41 PM, Clinton Stimpson wrote:
I assume these new failures are mine, but cannot reproduce it.
http://open.cdash.org/testDetails.php?test=222455969build=3128109
On 12/06/2013 02:51 PM, Daniele E. Domenichelli wrote:
If CMAKE_MINIMUM_REQUIRED_VERSION = 3.0.0, the NEW policy will be used,
but the author should also be warned that he should no longer include
the CMakeParseArguments.cmake file, since it will be deprecated and
might disappear in the
On 12/06/2013 03:11 PM, Matthew Woehlke wrote:
On 2013-12-06 14:51, Daniele E. Domenichelli wrote:
Are you sure you don't want the command to be renamed to
parse_arguments? The only commands containing cmake looks strictly
related to cmake, and the arguments parsing does not look that much
On 12/06/2013 01:32 PM, Brad King wrote:
The RunCMake.ExternalProject test failed almost everywhere last
night and still fails on every continuous. Please take a look.
Thanks for that fix. In order to untangle the topic from the
conflict with CMakeParseArguments_EmptyArgs I reverted both
On 12/06/2013 02:51 PM, Daniele E. Domenichelli wrote:
Actually ExternalProject, like several other modules, would probably
benefit on using the C++ implementation instead of having their own
parsing, or using the cmake implementation, but that's for a following
patch.
The ExternalProject
1. There is no longer a traverso mailing list that is active.
2. The original developers are impossible to get a hold of recently.
3. I do not have the original input parameters due to 1 and 2 above.
4. These lists are CMake and I am doing a rebuild of traverso making it
dependent upon both
On Fri, Dec 6, 2013 at 7:36 PM, outro pessoa outro.pes...@gmail.com wrote:
1. There is no longer a traverso mailing list that is active.
2. The original developers are impossible to get a hold of recently.
3. I do not have the original input parameters due to 1 and 2 above.
4. These lists are
18 matches
Mail list logo
