Expose qtests through buildsystem

[Manuel Breugelmans]

On Saturday 21 June 2008 12:06:31 Andreas Pakulat wrote:
> 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

Idea is to provide the same level of information as the cli version, not less. 
Not being able to tell a user the difference between a segfault, c-assert() 
or something else is a pretty big drawback in my book.

Manuel