target url from the project manager

Andreas Pakulat apaku at gmx.de
Thu Oct 16 15:25:32 UTC 2008


On 16.10.08 16:45:37, M Breugelmans 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.

Not as tough as you think. The problem is just that if we find one our
interface-classes to be insufficient, we'll need to copy it and give it a
new name (like adding _V2). Other API isn't quite that problematic, as you
can do a few things with classes in a BC-way to extend it. Not to mention
that you can still throw out the whole implementation under it of course.

Oh and also plugins are not affected by this, these rules only apply to our
public libraries. (not even the ones used inside some plugins to spread
code a bit)
 
> > 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

Agree.

> because it won't be 'managing'
> anything.

Disagree, as it provides the API to add a new test to a project, i.e. it
writes down the needed information into the project-files on disk (where
project-file != .kdev4 files, its CMakeLists.txt, foo.pro or somefile.xml)

> That's the responsibility of the veritas test model and should not be
> duplicated.

Then how does the model add the needed information to the CMakeLists.txt?

> ITestExecutableProvider, ITestExeSource or
> ITestExeProvider sounds better. This then holds a bunch
> TestExecutableInfo's.
> 
> class TestExecutableInfo {
> QString name() const;
> KUrl location() const;

I guess name is a ui-label and location is the actual executable-"thing"?
Also I think the workdir might be of interest.

> 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

Because I can't see a reason why we should force a buildsystem into the
whole thing. Not every project out there that has tests uses a buildsystem.
So one should be able to combine this interface with just IProjectManager
interface.

Andreas
 
-- 
You never hesitate to tackle the most difficult problems.




More information about the KDevelop-devel mailing list