Hi David,
thanks for your view.
I think if I want it to work in the most optimal way where ctest can
schedule all tests in the mega project for all sub projects in
accordance with its load balancing, the SubProject attribute would have
to become a property of the test, instead of being a global property.
In turn this would probably have to require a tweak in CDash's ingestion.
Would you agree with that?
For the time being I'll probably have to resort to using some scripts
that will create a CTest script per subproject, and execute those in turn.
Thanks,
W
On 01/09/17 20:39, David Cole wrote:
[External email]
I think your analysis is correct.
You could try doing a ctest_submit after each ctest_test call. Not
sure if you could get "correct" results with that technique. I run
some scripts that do something similar without subproject involved,
and it mostly works, but messes up the +/- tests passed and failed
since last submission data on the instance of CDash I'm using.
If you would like it to work differently than it presently does, it
would probably involve some changes to ctest. Making it do what you
want it to do and becoming a contributor is probably the quickest way
to achieve that.
HTH,
David C.
On Fri, Sep 1, 2017 at 2:36 PM, Wouter Klouwen
<wouter.klou...@youview.com> wrote:
Hi all,
I've been having some success with CTest and am interested in using
CDash as well.
In order to generate some nice output, sub projects seem to be the best
way of presenting the data in CDash for our setup. This setup is perhaps
summed up by having one projects that contains a few hundred projects.
Most of these "sub projects" are normal CMake projects.
Now, in the normal build, we have a `check` target. This is powered by
having tests added with add_test() and this check target invokes CTest
with a script that contains the setting of the SubProject property.
This produces the expected Test.xml with the SubProject tag. When
submitting these to CDash, it produces the right subproject view and the
expected aggregate view.
The next step is that we have code on devices for which we cross compile
and we want to use the same mechanism here in order to execute tests
when installed on our target devices.
Before I started the CDash work, I was able to generate CTest files
which contain the add_test() and set_tests_properties() in order to run
the tests on the devices. This was then invoked with the
DartConfiguration.tcl and ctest -T Test
Perhaps not ideal as it involves generated many CTestTestfile.cmakes,
but this was able to execute the several hundreds of tests with the
appropriate load balancing and produce one giant Test.xml.
In order to switch to generate Test.xml files with SubProject tags this
mechanism needs to be switched to using a CTest script.
As SubProject is a global property, I assume this needs to be unique for
each invocation of ctest_test().
Unfortunately putting multiple ctest_test() calls in one CTest script
seems to result in one Test.xml, which is the last project run. The test
of the output is overwritten.
It seems the only way I can make this work is by having a script which
effectively creates a new CTest script for each subproject, and moves
the produced Test.xml out of the way for the next run.
Is this right?
I hope this all makes sense.
Thanks in advance,
W
This transmission contains information that may be confidential and contain
personal views which are not necessarily those of YouView TV Ltd. YouView TV
Ltd (Co No:7308805) is a limited liability company registered in England and
Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower
Thames Street, London, EC3R 6YT. For details see our web site at
http://www.youview.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
[External email. Treat hyperlinks and attachments with caution]
This transmission contains information that may be confidential and contain
personal views which are not necessarily those of YouView TV Ltd. YouView TV
Ltd (Co No:7308805) is a limited liability company registered in England and
Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames
Street, London, EC3R 6YT. For details see our web site at http://www.youview.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
