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