target url from the project manager

[M Breugelmans]

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;
}

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