target url from the project manager

[Andreas Pakulat]

On 17.10.08 10:24:39, M Breugelmans wrote:
> On Thu, Oct 16, 2008 at 5:25 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> > 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:
> >> > 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)
> >
> > Then how does the model add the needed information to the CMakeLists.txt?
> 
> Well it's read-only and I'm not planning to change that. The
> buildsystem provides test executable information but not the other way
> around.

Thats completely ok. But you see we need a way to add tests into the
project, hence an interface is needed for doing so.

> >> 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.
> 
> I suppose it could be on IProjectFileManager instead.

Hmm, yeah. Probably makes it easier than putting it onto a separate class.

> Although I don't see it being meaningfull on anything else but IBSM's.
> For instance for pyunit it seems feasible to extract all information
> directly from DUChain.

I don't know about pyunit, but I have a very real-world case at hand where
I need a projectmanager (not buildsystem, thats not going to work anyway)
and still have the tests available :)

Andreas

-- 
Never commit yourself!  Let someone else commit you.