target url from the project manager

Aleix aleixpol at gmail.com
Fri Oct 17 00:06:18 UTC 2008


Well, this belongs to another thread.

So does everybody agree to remove the TestTarget item and add the ::url
method to the executable?

we can expose the test parameters in another way, is this fine?

Thanks,
Aleix

On Fri, Oct 17, 2008 at 12:58 AM, Andreas Pakulat <apaku at gmx.de> wrote:

> On 16.10.08 23:22:48, Aleix wrote:
> > On Thu, Oct 16, 2008 at 4:45 PM, M Breugelmans <mbr.nxi at gmail.com>
> wrote:
> > > On Thu, Oct 16, 2008 at 1:20 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> > > > 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".
> > >
> > > ITestManager is not a good name though because it won't be 'managing'
> > > anything. That's the responsibility of the veritas test model and
> > > should not be duplicated. ITestExecutableProvider, ITestExeSource or
> > > ITestExeProvider sounds better. This then holds a bunch
> > > TestExecutableInfo's.
> > >
> > > class TestExecutableInfo {
> > > QString name() const;
> > > KUrl location() const;
> > > QStringList arguments() const;
> > > QMap<QString, QString> properties() const;
> > > }
> >
> > Why not change location for ProjectExecutableTargetItem*?
> > That would make sense
>
> Thats exactly what Manuel explained a few mails ago in this thread. A test
> executable doesn't necessarily have to use a executable-target from the
> project. It can run anything from anywhere and Matt just explained a
> real-world use-case for this.
>
> So you might be able to feed the location() back into the project
> controller and find a target item for it. But this is not always the case.
>
> Andreas
>
> --
> You're growing out of some of your problems, but there are others that
> you're growing into.
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20081017/e0ed4cd3/attachment.html>


More information about the KDevelop-devel mailing list