target url from the project manager

[Aleix]

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:
> > 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:
> > 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.
>
> Hmm that's going to be though.
>
> >
> > 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

>
>
> Actually I'm not sure this provider interface is needed, why not even
> simpler with:
>
> QList<TestExecutableInfo> IBuildSystemManager::testExecutables() const;
> /// TestProvider Feature flag set if test-registration information is
> available
>
> Both cmake and ant have the notion of test properties. This could also
> hold a 'KDE4_ADD_UNIT_TEST' key provided by the cmake-duchain ...
>
>
> Manuel
>
> _______________________________________________
> 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/20081016/949c6f49/attachment.html>