[CMake] FindQt4.cmake returns too much irrelevant information

[Alan W. Irwin]

On 2009-05-07 22:45+0200 Christian Ehrlicher wrote:

> Alan W. Irwin schrieb:
>> I have just discovered that for -DCMAKE_BUILD_TYPE=Debug, the
>> combination of
>> FindQt4.cmake and UseQt4.cmake inserts the keywords debug, optimized, AND
>> general into the QT_LIBRARIES list to divide the list into three sections.
>> But only the debug section of that list is used by target_link_libraries
>> for
>> the -DCMAKE_BUILD_TYPE=Debug case.
>>
>> Could we have a cleaner design that doesn't specify the
>> target_link_libraries keywords and which simply returns in QT_LIBRARIES
>> whatever is relevant for the CMAKE_BUILD_TYPE that is specified?
>>


> CMAKE_BUILD_TYPE is not set for MSVC and other IDE generators so this
> will not work.

I thought that was a good argument at first, but when I looked deeper it
turns out not to be relevant to this particular case since the setting of
the debug and optimized keywords in FindQt4.cmake occurs inside a

IF (CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)

logic block.


> This would also mean that you can't change the buildtype
> without doing a complete research of the existing libraries.

I think that should be FindQt.cmake's job (i.e., return the correct library
results depending on whether and how CMAKE_BUILD_TYPE is set). I think it
should be straightforward to avoid re-searching the libraries each time.
(Get cached library search results and return what is relevant depending on
CMAKE_BUILD_TYPE.) Or did you mean something else?


> And CMAKE_BUILD_TYPE isn't use for some generators + is not set when you
> run cmake on a clean builddir without any options.

Actually, I have no complaints about FindQt4.cmake when CMAKE_BUILD_TYPE is
_not_ set.  But I do think it is a good idea to provide clean results when
CMAKE_BUILD_TYPE _is_ specified rather than a messy combination of
everything that _might_ be relevant.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________