Re: [cmake-developers] [PATCH] CMakeParseArguments: Test suite and native implementation

[Brad King]

On 12/14/2015 04:52 PM, Matthias Männich wrote:
> This adds a test suite for the CMakeParseArguments module. In addition
> the second change implements cmake_parse_arguments(...) as native
> command.

Thanks!  Applied with minor tweaks:

 CMakeParseArguments: add a RunCMake test suite
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cbbdfc2b

 CMakeParseArguments: replace by native cmake_parse_arguments command
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e8b14831

 cmake_parse_arguments: consider duplicate keyword as warning
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ab8a2808

and merged to 'next' for testing.

-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] Get the PYTHON_SITELIB directory in FindPythonLibs

[Brad King]

On 12/16/2015 05:04 AM, Andreas Schneider wrote:
> similar to what I implemented in FindPerlLibs.cmake some years ago, I've 
> added 
> PYTHON_SITELIB to FindPythonLibs. With PYTHON_SITELIB you have the location 
> where to install the python modules you built with cmake.
> 
> Example:
> 
> find_package(PythonInterp)
> find_package(PythonLibs)
> 
> python_add_module(my_py my_py.c)
> install(TARGETS my_py DESTINATION ${CMAKE_INSTALL_PREFIX}/${PYTHON_SITELIB})

One of the goals of FindPythonLibs is to work when cross-compiling such
that one cannot run the interpreter natively.  That is one reason we
don't just ask the interpreter where to get the libraries.  There has
been some discussion about doing such lookups conditionally when we
can run the interpreter but also having a fallback.

If there is another way to get this information then please use it.
Otherwise I'd rather not guarantee that we provide the information.
Projects can always run the same execute_process call themselves.

-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] Get the PYTHON_SITELIB directory in FindPythonLibs

[Andreas Schneider]

On Thursday 17 December 2015 11:12:13 Brad King wrote:
> On 12/16/2015 05:04 AM, Andreas Schneider wrote:
> > similar to what I implemented in FindPerlLibs.cmake some years ago, I've
> > added PYTHON_SITELIB to FindPythonLibs. With PYTHON_SITELIB you have the
> > location where to install the python modules you built with cmake.
> > 
> > Example:
> > 
> > find_package(PythonInterp)
> > find_package(PythonLibs)
> > 
> > python_add_module(my_py my_py.c)
> > install(TARGETS my_py DESTINATION
> > ${CMAKE_INSTALL_PREFIX}/${PYTHON_SITELIB})
> One of the goals of FindPythonLibs is to work when cross-compiling such
> that one cannot run the interpreter natively.  That is one reason we
> don't just ask the interpreter where to get the libraries.  There has
> been some discussion about doing such lookups conditionally when we
> can run the interpreter but also having a fallback.

If you look at the code, my changes to the code are inside an already existing

  if (PYTHON_EXECUTABLE)
  ...

So if you don't call find_package(PythonInterp) before 
find_package(PythonLibs) it will not get the PATH information for 
PYTHON_SITELIB.

The behavior of the module doesn't not change with this addition!

As it seems you did not look with enough context at the patch you can view the 
changes with more context (40 lines) here:

https://git.cryptomilk.org/users/asn/cmake.git/commit/?h=asn_pythonlibs=e414ea43caedeffeb27bb367b5f6c41e6238052a=40=0=0


Cheers,


-- andreas

-- 
Andreas Schneider   GPG-ID: CC014E3D
www.cryptomilk.orga...@cryptomilk.org
-- 

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 get_item_rpaths function: gp_append_unique for each rpath returned by "otool" command

[Brad King]

On 12/16/2015 08:22 AM, Emilie wrote:
> I attach a patch to fix the get_item_rpaths function

Thanks, applied:

 BundleUtilities: Fix handling of multiple RPATHs from OS X otool
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a479d7a0

-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 0015886]: FindHTMLHelp.cmake doesn't set HTMLHelp_FOUND variable

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15886 
== 
Reported By:grahamb
Assigned To:
== 
Project:CMake
Issue ID:   15886
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-12-17 12:14 EST
Last Modified:  2015-12-17 12:14 EST
== 
Summary:FindHTMLHelp.cmake doesn't set HTMLHelp_FOUND
variable
Description: 
The module doesn't set the corresponding package HTMLHelp_FOUND variable.  This
leads to erroneous reports that the package has not been found when using
FEATURE_SUMMARY

Steps to Reproduce: 
With this file:

cmake_minimum_required(VERSION 3.0)
set(CMAKE_FIND_LIBRARY_PREFIXES "")
set(CMAKE_FIND_LIBRARY_SUFFIXES "")

include(FeatureSummary)
find_package(HTMLHelp)
message(STATUS "HTML Help Compiler: ${HTML_HELP_COMPILER}")
feature_summary(WHAT ALL)

The output of CMake -P is:

-- HTML Help Compiler: C:/Program Files (x86)/HTML Help Workshop/hhc.exe
--
-- The following OPTIONAL packages have not been found:

 * HTMLHelp

Additional Information: 
Should the FOUND variable be dependent on the INCLUDE and LIBRARY?  Not sure.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-12-17 12:14 grahambNew 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] [CMake] How to set _default_ timeout for the ctest command? (fwd)

[Ben Boeckel]

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 project such as the above TIMEOUT property.

Here's the snippet from Brad's message:

> From the history of that code it looks like --timeout was added with
> no consideration of its relationship to CTEST_TEST_TIMEOUT.  Some
> other CTest options in the same scope as CTEST_TEST_TIMEOUT can be
> overridden by the command line, so I agree that --timeout should
> override it too.


http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/54086/focus=54168

which implies that --timeout sets CTEST_TEST_TIMEOUT, but any properties
would ignore the setting (as they do now).

--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] [CMake] How to set _default_ timeout for the ctest command? (fwd)

[David Cole via cmake-developers]

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 the test properties would be the best
approach for introducing changes in behavior. Or a **new**
--ignore-timeout-test-property to simply use the global value
everywhere for some use cases.


D



On Thu, Dec 17, 2015 at 12:53 PM, 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, i.e., override any
>> timeout set by the project such as the above TIMEOUT property.
>
> Here's the snippet from Brad's message:
>
>> From the history of that code it looks like --timeout was added with
>> no consideration of its relationship to CTEST_TEST_TIMEOUT.  Some
>> other CTest options in the same scope as CTEST_TEST_TIMEOUT can be
>> overridden by the command line, so I agree that --timeout should
>> override it too.
>
> 
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/54086/focus=54168
>
> which implies that --timeout sets CTEST_TEST_TIMEOUT, but any properties
> would ignore the setting (as they do now).
>
> --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
-- 

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] Get the PYTHON_SITELIB directory in FindPythonLibs

[Brad King]

On 12/17/2015 11:39 AM, Andreas Schneider wrote:
> If you look at the code, my changes to the code are inside an already existing
> 
>   if (PYTHON_EXECUTABLE)
>   ...
> 
> So if you don't call find_package(PythonInterp) before 
> find_package(PythonLibs) it will not get the PATH information for 
> PYTHON_SITELIB.

Sure, but if PYTHON_EXECUTABLE is set to refer to a binary that cannot
run on the host because it is part of a cross-compiling SDK then this
won't work.  Or, if PYTHON_EXECUTABLE can run on the host but it is
not the executable that corresponds to the libraries because the libs
are for another architecture then it will give wrong information.

-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] [CMake] How to set _default_ timeout for the ctest command? (fwd)

[Ben Boeckel]

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. However, what about script mode
which sets CTEST_TEST_TIMEOUT itself? Is CTEST_TEST_TIMEOUT readonly if
--timeout is given?

--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] CMakeParseArguments: Test suite and native implementation

[Alexander Neundorf]

On Thursday, December 17, 2015 11:12:22 Brad King wrote:
> On 12/14/2015 04:52 PM, Matthias Männich wrote:
> > This adds a test suite for the CMakeParseArguments module. In 
addition
> > the second change implements cmake_parse_arguments(...) as 
native
> > command.
> 
> Thanks!  Applied with minor tweaks:


Cool :-)
Faster and one module less to load and care about :-)

Alex

-- 

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] How to set _default_ timeout for the ctest command? (fwd)

[Alan W. Irwin]

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 / documented interactions
with the global variable and the test properties would be the best
approach for introducing changes in behavior. Or a **new**
--ignore-timeout-test-property to simply use the global value
everywhere for some use cases.


This seems like a reasonable approach to me to get these timeout issues
addressed.

However, to be clear, here are the consequences for a project like
lapack where some extrordinary but legitimate timing variations can occur.

1. The current advice to such projects would be to rigourously avoid setting 
either
CTEST_TEST_TIMEOUT or individual test timeout properties since the user 
currently
has no control over those (which illustrates why addressing the above
issues is important).

2. Once the --timeout fix that allows it to override
CTEST_TEST_TIMEOUT set by the project has become part of a release,
AND when that version of cmake is the minimum allowed by the project,
then it will be safe for the project to start using CTEST_TEST_TIMEOUT
since that value can now be overridden by the user with the --timeout
option. But the project should still rigourously avoid using
individual timeout properties until the conditions listed in 3. are
true.

3. Once the implementation of the proposed new --timeout-scale option
has been implemented and become part of a release, AND when that
version of cmake is the minimum allowed by the project, then it will
be safe for such projects to set both CTEST_TEST_TIMEOUT and
individual timeout properties since the user now has full control
over all such project timeouts.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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.sf.net); 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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [PATCH] FindBoost: Boost 1.60 support

[Roger Leigh]

With the release of Boost 1.60, I've updated FindBoost to work with this 
version.


Pushed to 
https://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/boost-1.60 
and merged into next for review.


- Adds 1.60.0 and 1.60 as valid versions
- Adds dependency information for 1.60; this is the same as for 1.59 
except that for "set(_Boost_LOG_DEPENDENCIES date_time log_setup ..." 
the date_time and log_setup dependencies were swapped.  I don't think 
this will make any difference, but including it to be on the safe side 
(it's harmless).


I have tested on Ubuntu 15.10 and Windows with VS2013, with projects 
using FindBoost against a locally compiled Boost 1.60.  They found Boost 
1.60 and its components, and compiled and linked and passed their unit 
tests.



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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] parallel install of different cmake versions

[Orion Poplawski]

On 12/14/2015 07:42 AM, Brad King wrote:

On 12/11/2015 06:42 PM, Orion Poplawski wrote:

For Fedora EPEL we often end up packaging newer versions of cmake as cmakeXY
(e.g. cmake34) that can be installed in parallel with the system cmake.  This
is a fairly invasive process.  I'm attaching the current patch I'm working on
for this.  Is there any interest in cmake itself for supporting this kind of
thing?


Not particularly.  That does look pretty invasive.

Why not just install it to /usr/lib/cmake34 with normal names and symlink
the versioned names?  E.g.

  /usr/bin/cmake34 -> /usr/lib/cmake34/bin/cmake
  /usr/bin/ctest34 -> /usr/lib/cmake34/bin/ctest
  ...

I have many different CMake versions installed on my system in different
directories and use aliases or symlinks to reference them without being
in my PATH directly.

-Brad



I'm not sure this would work.  There seems to be many places in the code 
(some of which the patch addresses) where it calls executes "cmake" or 
"ctest" regardless of the name it was called with.  If 
/usr/lib/cmake34/bin was not in the path (which would be the case with 
our EPEL packages unless we did more configuration) it would then end up 
calling the system cmake/ctest/etc.  This sounds like a recipe for 
disaster.  Or does cmake/ctest modify PATH internally?


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--

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] parallel install of different cmake versions

[Orion Poplawski]

On 12/14/2015 08:56 AM, Eric Noulard wrote:



2015-12-14 15:42 GMT+01:00 Brad King >:

On 12/11/2015 06:42 PM, Orion Poplawski wrote:
> For Fedora EPEL we often end up packaging newer versions of cmake as 
cmakeXY
> (e.g. cmake34) that can be installed in parallel with the system cmake.  
This
> is a fairly invasive process.  I'm attaching the current patch I'm 
working on
> for this.  Is there any interest in cmake itself for supporting this kind 
of
> thing?

Not particularly.  That does look pretty invasive.

Why not just install it to /usr/lib/cmake34 with normal names and
symlink
the versioned names?  E.g.

  /usr/bin/cmake34 -> /usr/lib/cmake34/bin/cmake
  /usr/bin/ctest34 -> /usr/lib/cmake34/bin/ctest



+1
Personnally when I installed several version of CMake I do install them
with a particular prefix and then I use update-alternatives(1) to install
proper symlinks to the specific location.

I switch from one version to another using update-alternatives(1).

This can certainly be used on Fedora/EPEL as well:
https://fedoraproject.org/wiki/Packaging:Alternatives


Yes, but this cannot be done in rpm spec files for building other 
packages (as would be done in EPEL).  Perhaps we could leverage 
environment-modules, but this would be a bit of a departure.



--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--

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] How to set _default_ timeout for the ctest command? (fwd)

[David Cole via cmake-developers]

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 CTEST_TEST_TIMEOUT should be ignored.

In either case, test property TIMEOUT should win/override to preserve the 
backwards compatibility for the use cases which currently depend on that.
 
Good scripts will wrap their setting of CTEST_TEST_TIMEOUT with an "if(NOT 
DEFINED" anyhow... Same with good projects.


David

> On Dec 17, 2015, at 2:42 PM, Ben Boeckel  wrote:
> 
>> 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. However, what about script mode
> which sets CTEST_TEST_TIMEOUT itself? Is CTEST_TEST_TIMEOUT readonly if
> --timeout is given?
> 
> --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] [CMake] How to set _default_ timeout for the ctest command? (fwd)

[David Cole via cmake-developers]

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 NOT set its 
default value.

Pretty standard to do "set only if not set" for variables that callers might 
potentially want to override in a ctest script or in a CMakeLists file.

This works with existing recent versions of cmake and ctest just fine... I 
think ctest has supported -D cmd line params since 3.0 or so.


David

> On Dec 17, 2015, at 6:38 PM, Alan W. Irwin  wrote:
> 
>> 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 / documented interactions
>> with the global variable and the test properties would be the best
>> approach for introducing changes in behavior. Or a **new**
>> --ignore-timeout-test-property to simply use the global value
>> everywhere for some use cases.
> 
> This seems like a reasonable approach to me to get these timeout issues
> addressed.
> 
> However, to be clear, here are the consequences for a project like
> lapack where some extrordinary but legitimate timing variations can occur.
> 
> 1. The current advice to such projects would be to rigourously avoid setting 
> either
> CTEST_TEST_TIMEOUT or individual test timeout properties since the user 
> currently
> has no control over those (which illustrates why addressing the above
> issues is important).
> 
> 2. Once the --timeout fix that allows it to override
> CTEST_TEST_TIMEOUT set by the project has become part of a release,
> AND when that version of cmake is the minimum allowed by the project,
> then it will be safe for the project to start using CTEST_TEST_TIMEOUT
> since that value can now be overridden by the user with the --timeout
> option. But the project should still rigourously avoid using
> individual timeout properties until the conditions listed in 3. are
> true.
> 
> 3. Once the implementation of the proposed new --timeout-scale option
> has been implemented and become part of a release, AND when that
> version of cmake is the minimum allowed by the project, then it will
> be safe for such projects to set both CTEST_TEST_TIMEOUT and
> individual timeout properties since the user now has full control
> over all such project timeouts.
> 
> Alan
> __
> Alan W. Irwin
> 
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
> 
> 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.sf.net); 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:
http://public.kitware.com/mailman/listinfo/cmake-developers