FindQt4.cmake synced with the version from cmake
Alexander Neundorf
neundorf at kde.org
Tue Dec 22 21:24:11 CET 2009
On Tuesday 22 December 2009, Thiago Macieira wrote:
> Em Terça-feira 22. Dezembro 2009, às 10.20.59, Mike Arthur escreveu:
> > On 22 Dec 2009, at 11:36, Thiago Macieira wrote:
> > > Yeah, that's what you said before.
> > >
> > > But my question is: if I want to link to a given libfoo, how do I know
> > > if it should be LIBRARY or LIBRARIES? Do I have to look into the
> > > documentation of the module, or is there a convention I can use to
> > > guess?
Yes, it should be in the documentation.
And that documentation should say that you should use the xxx_LIBRARIES
variable, and I think that's also the case for the majority of the modules.
> > You don't. This depends on the Find*.cmake module. Preempting your
> > response, I agree this is pretty stupid.
Well, it may be stupid, but at least as long as it is documented, it's not a
bug. Basically this depends on the authors of the find-modules.
> > > What happens if there's a technical change that requires now two
> > > libraries (like the Mac case)?
> >
> > Well, it'll still work unless you have it quoted, like the above example,
> > because then it will break the list of two libraries into a single
> > library with a space in the path.
>
> Can we then change the convention to use LIBRARIES, always, for all types
> of libraries?
From cmake/Modules/readme.txt:
XXX_LIBRARIES The libraries to link against to use XXX. These should
include full paths. This should not be a cache entry.
...
XXX_LIBRARY Name of XXX Library. A User may set this and XXX_INCLUDE_DIR to
ignore to force non-use of XXX.
So yes, we should use the LIBRARIES/LIBS variables.
There are also the QT_QTxxx_LIBRARIES variables.
Beside that, we can also make the new (for us) code in FindQt4.cmake handle
this differently.
Right now it does:
IF (CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
SET(QT_${basename}_LIBRARY optimized ${QT_${basename}_LIBRARY_RELEASE}
debug ${QT_${basename}_LIBRARY_DEBUG})
ELSE(CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
# if there are no configuration types and CMAKE_BUILD_TYPE has no value
# then just use the release libraries
SET(QT_${basename}_LIBRARY ${QT_${basename}_LIBRARY_RELEASE} )
ENDIF(CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
SET(QT_${basename}_LIBRARIES optimized ${QT_${basename}_LIBRARY_RELEASE}
debug ${QT_${basename}_LIBRARY_DEBUG})
ENDIF (QT_${basename}_LIBRARY_DEBUG AND QT_${basename}_LIBRARY_RELEASE)
I guess it would make sense to do this only if actually both versions have
been found. Also CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE could be
handled separately (set it to only one of the libs when CMAKE_BUILD_TYPE is
used, i.e. in makefiles, and ... not quite sure about the best way how to
handle CMAKE_CONFIGURATION_TYPES).
(nobody among the cmake developers is happy about the way
the "optimized/debug" feature is implemented, but it is there, so it has to
stay)
Alex
More information about the Kde-buildsystem
mailing list