target url from the project manager

[Andreas Pakulat]

On 16.10.08 12: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.

Yes, but nobody said that we'll have a 6 month release cycle, let alone
having only 6 months between major versions of the libs. Ideally I'd like
to not release a new major version of kdevplatform until Qt5 (and we're
rewriting it again :). At some point in time we will have to keep BC and
stick with minor version updates for at least 2-3 years. Else kdevplatform
is completely useless as nobody can count on it being a stable API to
program against. Thats the whole point of going through all the hoops
needed for BC, so that you can improve the product without needing a new
major version and breaking everybody's code.

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

See at the end.

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

No, target doesn't mean build-target, or rather what "build" means depends
totally on the underlying buildsystem. In particular Makefile based systems
can have anything as target, including ones that just open up an editor
with a readme file. Thats why we have an ProjectTargetItem class. It just
is some "thing" that other parts of the project can depend on.
 
> >  (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 :)

With the statement about veritas from above, I'm fine with removing the
test-target item altogether. 

However as far as I understood you still need an interface to find out the
tests inside a given project, right? If so we're back again to an
ITestManager interface, which is implemented by the project managers and
simply provides the interface that veritas needs to find the tests. And
possibly to add new tests to the underlying project - via the project
manager plugin. This doesn't duplicate anything, it simply allows you to
access the information in say CMakeLists.txt and foo.pro in a
buildsystem-independant way. Else veritas would need to have its own
CMakeLists.txt parser, its own qmake parser, its own parser for buildsystem
"foobar". 

Andreas

-- 
Change your thoughts and you change your world.