test retrieval

[Andreas Pakulat]

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:
> > On 16.11.08 12:33:03, M Breugelmans wrote:
> >> Test location information is now fetched through ctest, instead of
> >> through the KDevelop-cmake parser. It works by parsing
> >> CTestTestfile.cmake's in the build directory. The reasons behind this
> >> change are:
> >>
> >> - API in IProjectFileManager was no good, a generic approach for one
> >> specific case (cmake+ctest) is wrong.
> >
> > Thats just wrong. Sure we only had one implementation for the method, but
> > thats the case for almost any API in IBuildsystemManager.
> >
> > A few points why this is worse than letting the cmake parser handle it:
> 
> Well it's kitware's cmake parser that handles it now, I don't see how
> that's any worse.

One thing thats worse with it is that its slower than our parser.
 
> > - you're going to need to do the same thing for other buildsystems, to
> >  support their way of creating test-targets
> 
> Which other buildsystems provide this info? The only other I know of
> is ant for JUnit. They provide XML so that's virtually free to
> implement.

The one I'm using at work does, without makefiles or anything. And even if
a project uses specialized makefiles we should easily support that.

> > - there's no API for other parts to use if they want to access the Test
> >  executables
> 
> Could be added if it's needed, but not on ibuildsystem/ifilemanager it
> logically does not belong there. That belongs on ITestFramework or
> somesuch.

I don't care wether its a new interface or put onto an existing framework.

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

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.

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.

> > If parsing a ctest file is easier for veritas, then you can ignore the
> > test-executables. Nonetheless removing the working code and API that
> > provided access to the tests is wrong.
> 
> Unused code is dead code, dead code should be removed. Keeping stuff
> around just in case is a bit silly. But then I'm really not that
> bothered, note though that it has a couple of flaws.

Hmm, thats right indeed. So lets keep it out for now.

Andreas

-- 
Avert misunderstanding by calm, poise, and balance.