Moving the proxy model test suite to kdesupport?

Stephen Kelly steveire at gmail.com
Tue Jul 6 21:40:09 BST 2010


Andreas Pakulat wrote:

> On 03.07.10 15:13:08, Stephen Kelly wrote:
>> Hi,
>> 
>> The test suite for proxy models is growing inside
>> kdelibs/kdeui/tests/proxymodeltestsuite.
>> 
>> The unit tests for kselectionproxymodel and kdescendantsproxymodel depend
>> on the test suite library.
>> 
>> Last week I added a ModelEventLogger which is useful for debugging model
>> or proxy using applications, but as it is hidden inside kdeui/tests, the
>> only way to use the logger is to hack the CMakeLists to find the library
>> and headers.
>> 
>> I was thinking of moving the already self-contained proxymodeltestsuite
>> library into kdesupport.
> 
> Why not make it an installed part of kdelibs?

Because it is "test code" and I saw no need to write it with BC in mind. I 
still often change it in non-backward compatible ways and want to continue 
to do that.

> 
>> The library would be a build-time dependency for kdelibs and is needed
>> only when tests are being built.
> 
> Are you planning to maintain it and do regular releases (at least for
> new KDE releases)?

I'm trying to avoid exactly that, but at the same time make it available to 
developers of kde applications to use as a debugging tool.

> 
>> The disadvantage is that people wishing to build kdelibs tests would need
>> to build this external dependency. The advantage is that people hitting
>> an assert in kmail etc would just need to install the library from a well
>> known location, include the header and attach the logger. The library
>> would not need to be packaged or versioned as far as I'm concerned.
> 
> It has to, if it should be a proper library and a build dependency, that
> is it has to have a version and a soversion so that if you break BC in
> it you can let users know about this by changing the soversion. Same
> goes for doing releases, you'll have to so distro's have something to
> package.

I see no need for distros to package this stuff. It's purely a tool for 
developers debugging something model-view related to temporarily link to and 
include headers to.

> 
>> The proxymodeltestsuite library depends on Qt and my Grantlee
>> templating system.
> 
> So actually there'd be 2 new dependencies, the test (why the hell do I
> need a test library to build kdelibs?) 

It's already in kdelibs/kdeui/tests/ parts of it are used for the test 
harnesses in proxymodeltestapp and the kselectionproxymodeltest and 
kdescendantsproxymodeltest unit tests. It's just code sharing.

However, parts of it are also useful when debugging apps. It's useful not 
just in tests and unit tests. I want to make those things available easily.

> and that templating system (which
> is not available as package at least in debian currently, though thats
> not an immediate problem as there's enough time until kde4.6).

And it's a dependency of KJots 4.5, it's packaged in kubuntu and openSUSE 
already at least, and possibly others.

How about this: Instead of moving it anywhere, I add install() commands to 
the CMakeLists so that the library and headers are installed if kdelibs is 
installed with KDE4_BUILD_TESTS (or whatever the switch is). I can even 
install the headers to .../private/... if that would make a difference.

My experience here at akademy is that people who want to use the logger are 
unwilling to hack their CMakeLists to add the library and header path to 
their application. I'm not sure why not, but it seems it's not easy enough 
to access/use this stuff.

What do people think of that?

All the best,

Steve.

> 
> Andreas
> 






More information about the kde-core-devel mailing list