target url from the project manager

[Matt Rogers]

On Thursday 16 October 2008 05:08:33 M Breugelmans wrote:
> 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.
>

No, it applies for series numbers. So we can't break BC again until KDevelop 
5.

> > 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
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel

-- 
Matt