Expose qtests through buildsystem

[Andreas Pakulat]

On 21.06.08 10:41:13, Manuel Breugelmans wrote:
> On Friday 20 June 2008 20:06:10 Andreas Pakulat wrote:
> > On 20.06.08 17:47:58, Manuel Breugelmans wrote:
> > > On Friday 20 June 2008 15:51:54 Matt Rogers wrote:
> > > > On Friday 20 June 2008 07:27:35 am Manuel Breugelmans wrote:
> > > > > On Friday 20 June 2008 14:19:12 Aleix wrote:
> > > > > > Umm... I don't know if it is a good idea to get the .shell because
> > > > > > it is hard to use when debugging. I can provide the needed
> > > > > > LD_LIBRARY_PATH information though. :P
> > > > > >
> > > > > > Bye!
> > > > > > Aleix
> > > > >
> > > > > Hmm thats true, well if the info is available maybe they can both be
> > > > > exposed (wrapped and raw exe).
> > > > >
> > > > >
> > > > > Manuel
> > > >
> > > > And for the record, I never use the .shell executables when running my
> > > > tests. I always use the regular executable and it works fine.
> > >
> > > Well the main reason I prefer running the .shell's inside xtest is decent
> > > signal handling. QProcess is so nice as to only report
> > > NormalExit/CrashExit (maybe I missed something here?). QTestLib does not
> > > handle unix signals properly either, which it should ... eg Check does.
> > >
> > > So you'll have to go mess with 'QProcess::setupChildProcess' and
> > > <signal.h> to distinguish between a segfault & assert. The shell has
> > > robust OS independent signal handling for free, easy choice :)
> >
> > Please try to keep the code free from unix-only stuff, that makes
> > porting to other platforms a lot harder. I'm wondering what cmake
> > produces on win32 actually, IIRC it doesn't create a .bat or .cmd
> > file...
> 
> Right, thats exactly why that .shell should be called from xtest. No need for 
> messing with library paths nor unix signals. Anyway forget about it, I'll 
> just do + ".shell".

The problem is that only CMake supports that (and IIRC libtool too). But
for custom makefiles, custom buildsystems and even qmake you'll have to
fiddle around with at least the libraries.

I'm not sure I understand why you need to know wether a test aborts or
segfaults. Is that really needed for the results? Its failing in any
case and whoever looks at the results needs to look at the test too -
possibly running it manually to double-check why it fails. Did I miss
something?

Andreas

-- 
A visit to a strange place will bring fresh work.