target url from the project manager

[Matt Rogers]

On Thursday 16 October 2008 04:12:47 M Breugelmans wrote:
> On Wed, Oct 15, 2008 at 4:36 AM, Aleix <aleixpol at gmail.com> wrote:
> > hi list,
> > this was discussed some time ago but we didn't find anything good but we
> > didn't come up with a good interface for that. Now it is needed for the
> > new runcontroller, we want to be able to run any target.
> >
> > This is being solved in cmake adding the url to the UserData+1 (it is
> > already possible to run a target from the projectmodelview if it is
> > cmake), we need a way to specify it in the platform interface.
> >
> > Last time we spoke about many things, returning: KUrl, KUrl::List,
> > QMap<QString, KUrl> iirc. What do you think?
>
> The last one definitely not. IF that kind of information needs to be
> available it's better to hide it behind an interface/class of its own.
>
> > 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")
>
> This is legal cmake, but the 'foo' in the add_executable line is in no
> way related to 'foo' in the add_test line. So it is wrong to translate
> this to a TestTarget 'foo' with associated url
> <cmake-executable-dir>/foo. Only the kde4_add_unit_test macro links
> these two.
>

So? if it's not a URL, then an executable test target is not created for it. 
Right now, I have a project that uses CMake, but the QTest runner doesn't work 
because I use the exact same construct above, with the second parameter being 
a URL, just to provide an real world use case, rather than your convoluted 
one. Honestly, who's going to do: add_test( foo echo "test 123")?

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

Ant is another build system that comes to mind that this could be useful for.

Matt