target url from the project manager

[M Breugelmans]

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.

>> 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. 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.


Manuel