target url from the project manager

[M Breugelmans]

On Thu, Oct 16, 2008 at 11:38 AM, Andreas Pakulat <apaku at gmx.de> wrote:
> On 16.10.08 11:12:47, M Breugelmans wrote:
>> On Wed, Oct 15, 2008 at 4:36 AM, Aleix <aleixpol at gmail.com> wrote:
>> > Maybe we can add it only to test and executable target items
>>
>> Test-target items are a KDE only thing (as discussed a little on this
>> list before). That should be removed from the api, at least if
>> kdevelop aims to support cmake instead of kde-cmake :)
>>
>> enable_testing()
>> add_executable(foo foo.cpp)
>> add_test(foo echo "test 123")
>
> Hmm, I thought the test-foo would still create a real target.
>
>> 'echo "test 123"' is not a url ... Maybe this info should not be in
>> the IBuildSystemManager nor project model at all, but only available
>> through CMakeManager. Sure downcasting/RTTI is considered bad but
>> polluting these interfaces with cmake+ctest specific stuff is worse.
>> If, at some point, there's another build system implemented that
>> provides similar info then it could be moved to a general interface.
>
> There's two things I don't like much with your idea:
>
> a) we can't change interfaces once they're released without breaking BiC

I'm not familiar with BiC problems but doesn't that only apply in
between major releases? If that's the case it's not that much of a
problem with a 6-month release cycle.

> b) cmake would need to provide an interface to the manager and it would
> need to provide a way of retrieving tests and finding the "executable" for
> a test
>
> Which leads me to think: Why is this not part of the platform? Why don't we
> have something like ITestSystemManager or so, which allows to retrieve the
> tests inside a project, allows to add new ones and so on.

That would duplicate functionality with veritas, which already keeps
track of test exes. I have a partial redesign in mind that makes a
TestExecutable more of a prime citizen though.

> That is if we really don't want them as targets inside the project tree,
> which I still think might make sense even if not in all cases (like the
> above). I mean having an executable for a test is not necessarily a kde
> thing, one would probably do that in other cases as well. So a test-target
> would always have something that is executable

Target here (I think) means build-target, which it isn't. The cmake
add_test command does not add a make target, so KDevelop should not
try to do that either. Often you will have test scripts which need not
be build at all.

>  (the echo above is too), but
> it doesn't have to be a plain url. It might as well be a list of strings
> which are to be used for a process-run (arg0..argn). And internally we'll
> want to link a kde4 unit test target with its executable - not sure how to
> best do that inside the GUI though (as showing both would be strange).
>

If you are talking about the project-toolview: imo test information
should not be shown there. That's again duplication :)


Manuel