<div dir="ltr"><br><br><div class="gmail_quote">On Thu, Oct 16, 2008 at 4:45 PM, M Breugelmans <span dir="ltr"><<a href="mailto:mbr.nxi@gmail.com">mbr.nxi@gmail.com</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 Thu, Oct 16, 2008 at 1:20 PM, Andreas Pakulat <<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>> wrote:<br>
> On 16.10.08 12:08:33, M Breugelmans wrote:<br>
>> On Thu, Oct 16, 2008 at 11:38 AM, Andreas Pakulat <<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>> wrote:<br>
>> > On 16.10.08 11:12:47, M Breugelmans wrote:<br>
</div><div class="Ih2E3d">> Yes, but nobody said that we'll have a 6 month release cycle, let alone<br>
> having only 6 months between major versions of the libs. Ideally I'd like<br>
> to not release a new major version of kdevplatform until Qt5 (and we're<br>
> rewriting it again :). At some point in time we will have to keep BC and<br>
> stick with minor version updates for at least 2-3 years. Else kdevplatform<br>
> is completely useless as nobody can count on it being a stable API to<br>
> program against. Thats the whole point of going through all the hoops<br>
> needed for BC, so that you can improve the product without needing a new<br>
> major version and breaking everybody's code.<br>
<br>
</div>Hmm that's going to be though.<br>
<div class="Ih2E3d"><br>
><br>
> However as far as I understood you still need an interface to find out 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 buildsystem<br>
> "foobar".<br>
<br>
</div>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>
}</blockquote><div>Why not change location for ProjectExecutableTargetItem*?<br>That would make sense <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Actually I'm not sure this provider interface is needed, why not even<br>
simpler with:<br>
<br>
QList<TestExecutableInfo> IBuildSystemManager::testExecutables() const;<br>
/// TestProvider Feature flag set if test-registration information is available<br>
<br>
Both cmake and ant have the notion of test properties. This could also<br>
hold a 'KDE4_ADD_UNIT_TEST' key provided by the cmake-duchain ...<br>
<br>
<br>
Manuel<br>
<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>