Installed tests

Andreas Pakulat apaku at gmx.de
Wed Jun 20 01:39:06 CEST 2007


On 19.06.07 19:08:20, Alexander Neundorf wrote:
> On Tuesday 19 June 2007 06:15, Andreas Pakulat wrote:
> > On 19.06.07 11:56:32, Olivier Goffart wrote:
> > > Le mardi 19 juin 2007, Andreas Pakulat a écrit :
> > > > On 19.06.07 10:14:26, David Faure wrote:
> > > > > On Monday 18 June 2007, Andreas Pakulat wrote:
> > > > > > Hi,
> > > > > >
> > > > > > it seems my changes did have an unfortunate impact on installed
> > > > > > tests. Two users reported an installing problem with kdelibs on IRC
> > > > > > and it seems the problem is that knotifytest in knotify/test is
> > > > > > installed. The problem is that the install() commands in the
> > > > > > CMakeLists.txt are not guarded anymore.
> > > > >
> > > > > Why should knotifytest *ever* be installed?
> > > >
> > > > I have no idea, but it is including a rc-file. The svn log indicates
> > > > that this was ported from automake. I'm CC'ing the original author
> > > > Olivier Goffart.
> > > >
> > > > Olivier is there a particular reason why knotifytest needs to be
> > > > installed? Or can the install-lines be removed from CMakeLists.txt in
> > > > kdelibs/knotify/tests?
> > >
> > > There is indeed no reason to install the binary of this test.  Anyway,
> > > the knotifytest.knotifyrc must be installed in a proper location in order
> > > the test to work.
> >
> > Ok, that part can go then.
> 
> So the problem was:
> 
> add_executable(foo EXCLUDE_FROM_ALL main.cpp)
> install(TARGETS foo DESTINATION bin)
> 
> where the install failed if foo wasn't built, right ?

Not really, the problem was that make started to build foo, but foo
needed a .ui file to be processed which didn't happen because foo wasn't
built explicitly.

> > > But this file should not be installed in a non test environment because
> > > it add unnecessary entry in the knotify control module. So maybe we can
> > > just disable this test, and if one want to test, one need to install
> > > manually files
> >
> > Ok, so the original problem still exists: Installing certain files when
> > building a test (or installing them with make install only if the test
> > was built before), without having to specify -DKDE4_BUILD_TESTS. Any
> > ideas how/if this is possible with cmake
> >
> > I think there may be quite some other things that are of the same form
> > (a rc or desktop file that needs to be installed for the test to work).
> 
> There should be no problem installing some desktop or rc files no matter 
> whether a target is built or not.

Right, except that this will give packagers a headache, they have to
explicitly deselect these file then.

> I have the impression that we are trying to do something with regard to the 
> tests which isn't supported by cmake/ctest and we are now trying to add more 
> and more hacks to make it behave somewhat like what we want.
> 
> So, what do we need ?
> 
> (please don't answer how it worked with autotools, but the features which are 
> needed)
> 
> ctest knows the names of all tests created using ADD_TEST().

this is not using add_test, because this is not a unit-test. Its just a
target that is only built by doing make <target> or by specifying
-DKDE4_BUILD_TESTS=on. And obviously the test needs a file to be
installed to be executed.

> Would it help if ctest would build the test executables if they haven't been 
> built before it tries to run the tests ?

Thats something I already brought up on the cmake lists a few weeks ago
- IIRC. Not sure what the result was though. This is something that
makes sense IMHO because if I ask to run a few tests I surely want to
build them as well. And some people are crazy using ruby scripts to
create tests for parsers, where you end up with 20 of them. Nobody wants
to do make 20x<targetname> ;)

Andreas

-- 
Your lucky number has been disconnected.


More information about the Kde-buildsystem mailing list