<div dir="ltr">Well, this belongs to another thread.<br><br>So does everybody agree to remove the TestTarget item and add the ::url method to the executable?<br><br>we can expose the test parameters in another way, is this fine?<br>
<br>Thanks,<br>Aleix<br><br><div class="gmail_quote">On Fri, Oct 17, 2008 at 12:58 AM, Andreas Pakulat <span dir="ltr"><<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On 16.10.08 23:22:48, Aleix wrote:<br>
> On Thu, Oct 16, 2008 at 4:45 PM, M Breugelmans <<a href="mailto:mbr.nxi@gmail.com">mbr.nxi@gmail.com</a>> wrote:<br>
> > On Thu, Oct 16, 2008 at 1:20 PM, Andreas Pakulat <<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>> wrote:<br>
</div><div><div></div><div class="Wj3C7c">> > > However as far as I understood you still need an interface to find out<br>
> > the<br>
> > > tests inside a given project, right? If so we're back again to an<br>
> > > ITestManager interface, which is implemented by the project managers and<br>
> > > simply provides the interface that veritas needs to find the tests. And<br>
> > > possibly to add new tests to the underlying project - via the project<br>
> > > manager plugin. This doesn't duplicate anything, it simply allows you to<br>
> > > access the information in say CMakeLists.txt and <a href="http://foo.pro" target="_blank">foo.pro</a> in a<br>
> > > buildsystem-independant way. Else veritas would need to have its own<br>
> > > CMakeLists.txt parser, its own qmake parser, its own parser for<br>
> > buildsystem<br>
> > > "foobar".<br>
> ><br>
> > ITestManager is not a good name though because it won't be 'managing'<br>
> > anything. That's the responsibility of the veritas test model and<br>
> > should not be duplicated. ITestExecutableProvider, ITestExeSource or<br>
> > ITestExeProvider sounds better. This then holds a bunch<br>
> > TestExecutableInfo's.<br>
> ><br>
> > class TestExecutableInfo {<br>
> > QString name() const;<br>
> > KUrl location() const;<br>
> > QStringList arguments() const;<br>
> > QMap<QString, QString> properties() const;<br>
> > }<br>
><br>
> Why not change location for ProjectExecutableTargetItem*?<br>
> That would make sense<br>
<br>
</div></div>Thats exactly what Manuel explained a few mails ago in this thread. A test<br>
executable doesn't necessarily have to use a executable-target from the<br>
project. It can run anything from anywhere and Matt just explained a<br>
real-world use-case for this.<br>
<br>
So you might be able to feed the location() back into the project<br>
controller and find a target item for it. But this is not always the case.<br>
<br>
Andreas<br>
<font color="#888888"><br>
--<br>
You're growing out of some of your problems, but there are others that<br>
you're growing into.<br>
</font><div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</div></div></blockquote></div><br></div>