On Mon, Dec 14, 2015 at 23:01:31 -0800, Alan W. Irwin wrote:
> On the cmake general list, Brad recently answered my original query on this
> subject and appears to agree with me that that ctest --timeout
> option should always have the highest priority, i.e., override any
> timeout set by the
I agree with Brad, the --timeout command line parameter should only
set/override the variable CTEST_TEST_TIMEOUT. The behavior w.r.t. test
TIMEOUT properties should be left as is for this change.
A **new** --timeout-scale with well defined / documented interactions
with the global variable and
On Thu, Dec 17, 2015 at 13:54:08 -0500, David Cole wrote:
> I agree with Brad, the --timeout command line parameter should only
> set/override the variable CTEST_TEST_TIMEOUT. The behavior w.r.t. test
> TIMEOUT properties should be left as is for this change.
This behavior also makes sense to me.
On 2015-12-17 13:54-0500 David Cole wrote:
I agree with Brad, the --timeout command line parameter should only
set/override the variable CTEST_TEST_TIMEOUT. The behavior w.r.t. test
TIMEOUT properties should be left as is for this change.
A **new** --timeout-scale with well defined /
The principle "most local setting wins" should be followed.
If a script is called without --timeout cmd line param, CTEST_TEST_TIMEOUT
applies, if set. Otherwise default timeout value.
If a script is called with --timeout cmd line param, then that **is** the
timeout value, and
Sounds to me like lapack should conditionally set CTEST_TEST_TIMEOUT only if
it's not DEFINED already. With such code in the project, callers could define
it on the command line with -D, or directly in a ctest -S script, and the
passed in vale would "win" since in this case, the project would
On Mon, Dec 14, 2015 at 23:01:31 -0800, Alan W. Irwin wrote:
> On the cmake general list, Brad recently answered my original query on this
> subject and appears to agree with me that that ctest --timeout
> option should always have the highest priority, i.e., override any
> timeout set by the
Thanks, Ben. That was gonna be my 2 cents, too:
If I set a test property to have a 1, 5 or 10 second timeout, then I
want the test to timeout if it takes any longer than that. I do this
on tests which must execute quickly even in a loaded CPU scenario. I
would not want the global timeout to take
On 2015-12-15 13:53-0500 Ben Boeckel wrote:
On Tue, Dec 15, 2015 at 10:33:38 -0800, Alan W. Irwin wrote:
On 2015-12-15 11:20-0500 Ben Boeckel wrote:
I think, instead, that --min-timeout and --max-timeout options might be
better which allow you to say "this machine is slow; tests may take
On Tue, Dec 15, 2015 at 10:33:38 -0800, Alan W. Irwin wrote:
> On 2015-12-15 11:20-0500 Ben Boeckel wrote:
> > I think, instead, that --min-timeout and --max-timeout options might be
> > better which allow you to say "this machine is slow; tests may take
> > longer (max(property, option))" or
On 2015-12-15 11:20-0500 Ben Boeckel wrote:
On Mon, Dec 14, 2015 at 23:01:31 -0800, Alan W. Irwin wrote:
On the cmake general list, Brad recently answered my original query on this
subject and appears to agree with me that that ctest --timeout
option should always have the highest priority,
On 2015-12-15 07:09+0100 Attila Krasznahorkay wrote:
Hi Alan,
Are you just looking for the TIMEOUT property on the tests?
Hi Attila:
No. As I said in my post, I tried that test property but
the problem was that absolutely fixed the timeout for the test
so it could not be overriden by the
Hi Alan,
Are you just looking for the TIMEOUT property on the tests?
https://cmake.org/cmake/help/v3.0/command/set_tests_properties.html
This is something that I managed to find with the most basic google-ing myself.
:-/ And I use it like:
set_tests_properties( ${testName}Test PROPERTIES
I would appreciate it if a CMake developer who is familiar with the CTest
timeout
logic would answer my question below that was addressed to
"@CMake developers:".
Without such an answer (even if the conclusion is there is no way for
an individual software package such as lapack to set a
14 matches
Mail list logo