> Great, thanks.  However, we really need to have the cmake_common.cmake script 
> used to drive it

The nightly build that I use does use the "cmake_common.cmake" script to grab 
the latest code, build, test it, etc. Here's what my nightly build results look 
like: https://open.cdash.org/buildSummary.php?buildid=3701008.

> Any tests depending on local system configuration need to have an option to 
> explicitly enable them on such systems.  See the existing 
> CMake_TEST_FindJsonCpp option for example.
> Just put your new test(s) inside a condition on a CMake_TEST_GreenHillsMULTI 
> variable.  Then add to your dashboard script::
>
> set(dashboard_cache "
> CMake_TEST_GreenHillsMULTI:BOOL=ON
> ")
>
> before including cmake_common.cmake and the tests will be enabled once they 
> are in the repo.

I made that small change in the attached patch.

I ran another experimental build in debug. Here are those results: 
https://open.cdash.org/buildSummary.php?buildid=3701457. I expected the 
"CMakeOnly.MajorVersionSelection-PythonInterp_2" to fail because I have the 
Python 3.3 executable in my path. But I still get the "CMake.GetPrerequisites" 
test timing out. Also, I haven't debugged the warnings in the Build row yet. 
This suit of tests was done using a script based on the autogenerated 
"CTestScript.cmake" script.


Geoffrey Viola
SOFTWARE ENGINEER
asirobots.com



-----Original Message-----
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Tuesday, February 17, 2015 9:02 AM
To: Geoffrey Viola
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] Initial Attempt at Green Hill MULTI IDE 
Generator Support

On 02/17/2015 10:47 AM, Geoffrey Viola wrote:
> I submitted a test report with all the tests passing.
> https://open.cdash.org/buildSummary.php?buildid=3698090.

Great, thanks.  However, we really need to have the cmake_common.cmake script 
used to drive it.  What I was asking in my previous response was for you to get 
a normal nightly testing dashboard submission configured and working 
independent of your changes.  For that using the common script with 
ctest_update is okay.

> I'm not sure how to handle cases where the user wants to run all the
> test and expects all to pass, but does not have Green Hills installed.

Any tests depending on local system configuration need to have an option to 
explicitly enable them on such systems.  See the existing 
CMake_TEST_FindJsonCpp option for example.  Just put your new test(s) inside a 
condition on a CMake_TEST_GreenHillsMULTI variable.  Then add to your dashboard 
script::

 set(dashboard_cache "
 CMake_TEST_GreenHillsMULTI:BOOL=ON
 ")

before including cmake_common.cmake and the tests will be enabled once they are 
in the repo.

Thanks,
-Brad

This message contains confidential information and is intended only for the 
recipient. If you are not the named addressee you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately if you 
have received this e-mail by mistake and delete this e-mail from your system. 
Finally, the recipient should check this email and any attachments for the 
presence of viruses. The company accepts no liability for any damage caused by 
any virus transmitted by this email.

Attachment: 0001-Added-some-support-for-a-Green-Hills-MULTI.patch
Description: 0001-Added-some-support-for-a-Green-Hills-MULTI.patch

-- 

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

Reply via email to