[CMake] FindQt4.cmake returns too much irrelevant information

[Alan W. Irwin]

On 2009-05-08 10:07-0600 Clinton Stimpson wrote:

> Alan W. Irwin wrote:
>> 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.
>
> Its not clear to me how you'd make a .pc file for pkg-config for someone who 
> chooses to build PLplot with a generator that ignores CMAKE_BUILD_TYPE.

The approach used is to simply copy whatever compiler and linker flags 
cmake is aware of to the *.pc file.  Of course, if there is a generator
setting up some sort of IDE where additional/different compiler and linker
flags that the generator is not aware of might be used for the build, then
the pkg-config approach (or any approach which depends on CMake knowledge of
compile and link flags) will not work as well.  I am not that familiar with
the IDE approach so I don't know whether that is a theoretical concern or a
practical one.  But what I do know is that pkg-config has served the needs
of our Unix users for many years (even long before we switched to a
CMake-based build system) and Windows users recently.  Therefore, we will
continue to export the compiler and link flags that CMake is aware of via
pkg-config.

> From what I can tell, it seems you're asking for a change to FindQt4.cmake to 
> support making a CMakeLists.txt that is less-portable.

Nope.  Although PLplot ran afoul of the current unclean design of
FindQt4.cmake via our attempts to export compile and link information via
pkg-config, that is not the principal issue since we can work around that
limitation for ourselves. Instead, my appeal was for a clean design for how
the QT4 information was returned to the CMake environment.  The
FindQT4.cmake logic that mixes in keywords with QT_LIBRARIES only does that
if CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE are set.  For that case,
you know which part of the mixture of libraries should be put into
QT_LIBRARIES. Why return the entire mixture of possibilities in
QT_LIBRARIES?  I can see no justification for that unclean design, and I am
concerned that design will trip up other use cases in the future that are
not anticipated at this time.

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
__________________________