test retrieval

[Andreas Pakulat]

On 16.11.08 22:44:09, M Breugelmans wrote:
> 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).

Hmm, hope it respects my choice to remove a particular test after I've
written it and it works :)

> 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.

IMHO the run-test-suite action should just have an option to automatically
build (and possibly install). In fact it would be nice to integrate that
into the run-support at some point, so I can start executables as well as
test-suite runs from the same place.

> A reload can be expensive anyway because it also involves calling the
> qtest executables with the --function flag.

QTest unit-tests are just one possibility.
 
> > 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.

I guess the usual limit of about 8000 files that can be watched at the same
time with one KDirWatch instance won't be hit with tests... But you can
rather easily catch the removal by listening to the buildsystem signals,
thats what they're there for.
 
> > 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.

Well, there's only a handful of signals, so scaling shouldn't be a real
problem. And just the built-signal means the user has to trigger a build
before the test-run works, which is not very nice. It should "just work" ;)

Andreas
 
-- 
Exercise caution in your daily affairs.