test retrieval

M Breugelmans mbr.nxi at gmail.com
Sun Nov 16 15:24:50 UTC 2008


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.

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

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

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

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


Manuel




More information about the KDevelop-devel mailing list