Expose qtests through buildsystem

[Manuel Breugelmans]

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

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


Manuel