<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-02-06 14:34 GMT+01:00 Friedrich W. H. Kossebau <span dir="ltr"><<a href="mailto:kossebau@kde.org" target="_blank">kossebau@kde.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am Freitag, 6. Februar 2015, 08:08:53 schrieb Elvis Stansvik:<br>
<span class="">> But, re. running certain only certain sets of test, perhaps we could label<br>
> tests using<br>
><br>
> set_tests_properties(SomeTest SomeOtherTest PROPERTIES LABELS "stress")<br>
> set_tests_properties(FooTest BarTest PROPERTIES LABELS "integration")<br>
<br>
</span>Nice, did not know, that indeed might help us to get somewhere.<br></blockquote><div><br></div><div>Yep. Me neither, found through some googling.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> and then pass -L / -LE to ctest using e.g.<br>
><br>
> make test ARGS="-LE integration"<br>
<br>
</span>Oh, something new I could learn here, Makefile macro definition by arguments<br>
to make, interesting :)<br>
Just, that "ARGS" cmake macro is not really defined somewhere, or? Found it in<br>
the generated Makefile for the "test" target. Possibly some legacy thing and<br>
only traded in secret circles :)<br></blockquote><div><br></div><div>Yea, that's how I found it too. And then found what to google for, and indeed some people seem to make use of it. But like you say, not documented afaics :/ Perhaps we could nudge to CMake folks to make this a supported thing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Played a little with that locally, and think this is worth to investigate more<br>
into.<br>
<br>
Assuming the properties "stress", "integration" and "unit" are mutual<br>
exclusive, I guess having some convenience wrappers might make sense, e.g.<br>
having these dedicated macros<br>
<br>
calligra_add_unittest<br>
calligra_add_integrationtest<br>
calligra_add_stresstest<br>
<br>
defined like e.g.<br>
<br>
macro(calligra_add_unittest _test_NAME)<br>
set(_targetName ${_test_NAME})<br>
if( ${ARGV1} STREQUAL "TESTNAME" )<br>
set(_targetName ${ARGV2})<br>
endif()<br>
kde4_add_unit_test(${_test_NAME} ${ARGN})<br>
set_tests_properties(${_targetName} PROPERTIES LABELS "UNITTEST")<br>
endmacro()<br>
<br>
This should protect against typos and keep the code simple.<br>
<br>
And invoking them might be doable by separate targets, e.g.<br>
<br>
add_custom_target(unittest<br>
COMMAND ctest --force-new-ctest-process -L \"UNITTEST\")<br>
<br>
so on the command-line<br>
make unittest<br>
will result in the test run, but just of all unittests.<br></blockquote><div><br></div><div>Yep. All the sugar above sounds nice.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Have just pinged also sysadmin by a ticket for their experience and proposals,<br>
how our requirements could be solved on CI side, i.e. everything built but<br>
only env-independent tests run there.<br></blockquote><div><br></div><div>Great.</div><div><br></div><div>Elvis</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
Cheers<br>
Friedrich<br>
_______________________________________________<br>
calligra-devel mailing list<br>
<a href="mailto:calligra-devel@kde.org">calligra-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/calligra-devel" target="_blank">https://mail.kde.org/mailman/listinfo/calligra-devel</a><br>
</div></div></blockquote></div><br></div></div>