test retrieval

M Breugelmans mbr.nxi at gmail.com
Sun Nov 16 21:44:09 UTC 2008


On Sun, Nov 16, 2008 at 6:00 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> On 16.11.08 16:24:50, M Breugelmans wrote:
>> On Sun, Nov 16, 2008 at 3:11 PM, Andreas Pakulat <apaku at gmx.de> wrote:
>> > - The user now has to re-run build before he'll see changes to the
>> >  CMakeLists.txt file for the tests.
>>
>> That's good actually. For my use case you don't want new
>> test-executable info before they are build.
>
> I'm pretty sure you'll get bugreports about: "I've created a new test and
> now I can't add it", because they're used to automatic-build-before-run.
> But they can't run, because its not known - even though CMake knows about
> it.

There's no add test phase, it will happen automatically for you after
each build (todo though). With both a run-test-suite and a
build+run-test-suite action it should be clear enough that the model
only refreshes after each successful build. A reload can be expensive
anyway because it also involves calling the qtest executables with the
--function flag.

If you are talking about 'run current-test': for that this test
discovery won't be used.

> Also, what about removing tests? That will create problems because people
> will have to re-run configure on the project (or build) just to let the
> test-framework know that a target doesn't exist.

Suppose I could detect if some executable is removed from disk.

> If you really want to do this, you need to connect the various
> project/buildsystem manager signals and re-run cmake automatically on your
> side to update the file.
>

I don't think that would scale very well if done for all kinds of
signals, just the succesfull-build one seems enough.


Manuel




More information about the KDevelop-devel mailing list