FYI: Updates in ThreadWeaver

[Stephen Kelly]

David Faure wrote:

> On Wednesday 03 April 2013 10:09:56 Mirko Boehm wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> On 04/02/2013 05:05 PM, Sebastian Kügler wrote:
>> >> - - Examples are currently in the kdelibs tree, at
>> >> 
>> >> > tier1/threadweaver/examples. I like that they are in the same
>> >> > repository, but still - is this the right place?
>> > 
>> > If not, we have the kdeexamples repository for such things.
>> 
>> Two more questions:
>> 
>> - - I have some code that should only be compiled for debug builds. Which
>> is the preferred macro to do that? At the moment, I am using the
>> classical NDEBUG, which probably is not what we are using:
>> 
>> #if not defined NDEBUG
>>     d->debugExecuteWrapper.wrap(setExecutor(&d->debugExecuteWrapper));
>> #endif
> 
> Seems fine to me, we already use that in other bits of code (e.g.
> kdirlister.cpp).
> cmake sets that in release mode AFAIK.
> 
>> - - As for tests, I now have four unit tests programs amounting to ~40
>> tests total. One of them has 28 of the tests. I wonder if I should
>> simply put all the tests into one unit test binary, or not. Note that
>> this does not include benchmarks, those are separate. What is the
>> preferred way?
> 
> Volker's answer is an interesting data point. Not that the ksycoca-related
> tests are ready for parallelism though.

Note that ctest also allows you to specify 'resource locks' so that tests 
which use the same resources do not get run at the same time.

$ cmake --help-property RESOURCE_LOCK
cmake version 2.8.10.1
  RESOURCE_LOCK
       Specify a list of resources that are locked by this test.

       If multiple tests specify the same resource lock, they are guaranteed
       not to run concurrently.


So, if the sycoca tests have something like 

 set_property(TARGET ${_testname} APPEND PROPERTY RESOURCE_LOCK sycoca)

they'll all run serially to each other, in parallel with all the other 
tests.

Of course, once we split the repos, this won't matter so much anyway.

Thanks,

Steve.