Silencing dependencies finding tests

[Alexander Neundorf]

On Thursday 08 May 2008, Friedrich W. H. Kossebau wrote:
> Am Mittwoch, 7. Mai 2008, um 23:24 Uhr, schrieb Alexander Neundorf:
> > On Thursday 01 May 2008, Friedrich W. H. Kossebau wrote:
> > > Hi,
> > >
> > > the kdeutils/printer-applet/cmake-modules/FindPyQt4.cmake check
> > > produces some noise if PyQt4 is not found:
> > >
> > > --- 8< ---
> > > Traceback (most recent call last):
> > >
> > > File
> > > "/home/koder/Kode/kdesvn/trunk/KDE/kdeutils/printer-applet/cmake-module
> > >s/ FindPyQt.py", line 9, in <module>
> > >     import PyQt4.pyqtconfig
> > > ImportError: No module named PyQt4.pyqtconfig
> > > --- 8< ---
> > >
> > > Now I saw in the cmake docs one can silence this error by adding the
> > > parameter ERROR_QUIET to the EXECUTE_PROCESS() call, e.g.
> > > 	EXECUTE_PROCESS(COMMAND ${PYTHON_EXECUTABLE}
> > > 		${_cmake_module_path}/FindPyQt.py
> > > 		OUTPUT_VARIABLE pyqt_config ERROR_QUIET)
> > >
> > > Is this the way to go? Or should there be also some support for verbose
> >
> > I think so.
> > Another option would be to catch the error output in its own variable and
> > do something with it.
>
> But what something? IIRC with auto* there was a verbose log file. Which
> could be used to see why exactly a check was falling ("No PyQt4? Heck, I
> think I do have it installed...")
>
> I imagine some macros named e.g.
> 	macro_log_check_output()
> 	macro_write_check_output_log()
> to do this, analog to the macro_log_feature ones.
>
> But I have no idea, if somebody really makes use of such check output logs.
> I think I did a few times.

This is taken from Modules/CheckIncludeFile.cmake:

     FILE(APPEND ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeError.log 
        "Determining if the include file ${INCLUDE} "
        "exists failed with the following output:\n"
        "${OUTPUT}\n\n")

So you can use file(APPEND ... ) to CMakeError.log (CMakeOutput.log for 
non-error messages) to record such problems.

Alex