Re: [cmake-developers] FinQt4/UseQt4 / module QtWebKit isn't found with Qt 4.8.1 even if installed
On 05/16/2012 06:51 AM, Adrien Guinet wrote: Hello everyone, It seems that, in Qt 4.8.1 (at least in the Debian packages), the QtWebKit module isn't shipped in a separated .so (libQtWebKit.so). Thus, this makes FindQt4.cmake fails to find the QtWebkit modules, beucase a module is considered found when both its libraries files and directories are found. As a consequence, include directories are not set if the QT_USE_QTWEBKIT variable is set to TRUE (for instance), and code fails to compile. I don't know if this is an issue with the Debian packages of Qt (last packages in sid as of today), or if Qt decided to build QtWebkit within QtGui. Attached to this mail is a temporary patch (well, an ugly *hack* actually) that I am using (against FindQt4.cmake) : Thanks for any help or comments about this ! Regards, Do you have the libqtwebkit-dev package installed? Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] set_property(DIRECTORY) regression ?
Brad King wrote: On 5/14/2012 5:18 PM, Alexander Neundorf wrote: This is the output I get when running the attachec example with cmake 2.6.4 and 2.8.0: The behavior of properties did not change. There was a bug in CMake 2.6 that was fixed here: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=21fc04ef The patch below works around this bug in 2.6 and shows that the behavior is the same for 2.6 and 2.8 in terms of the property inheritance. Directory properties are not inherited by default. The define_property() command may be used to change that for user-defined properties by using the INHERITED option: http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command:define_property I've never used that in a real project though. Thanks for the feedback on this and the suggestion. Actually that define_property was also in Michaels suggestion[1], but when it required me to specify FULL_DOCS and BRIEF_DOCS arguments, I thought it didn't seem suitable for something which is internal and autogenerated (And I didn't know what effect it would have :) ). [1] http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/7165/focus=41551 Given that the variable or directory property guards are more complex to maintain, and given that the point of their existance is to guard against accidental naming clash between the imported targets and targets created as part of a buildsystem, and given that Qt5::Foo is already unusual enough that name clashes are unlikely, I just changed it to use IF(NOT TARGET) instead [2]. [2] https://codereview.qt-project.org/#change,26253 Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Handling of Config specific imported targets?
Hi there,
In Qt 5 we currently generate IMPORTED_LOCATION_${Config} for the Debug or
Release (or both, depending on platform), depending on how Qt is configured.
If both exist (on windows) and the caller uses CMAKE_BUILD_TYPE == Debug or
Release, the correct location should be used. However, this doesn't account
for having a different or empty CMAKE_BUILD_TYPE.
If the Config doesn't match any available IMPORTED_LOCATION_${Config}, then
it seems from my testing that the first one set is chosen. This means that
for example if I have a PROFILING Configuration, which should use the
release libraries, but Debug appears first in the generated Config file (as
it does), then the wrong IMPORTED_LOCATION would be used.
I have written a patch that changes the behavior to not create a
IMPORTED_LOCATION_${Config} for both Debug and Release unless necessary. If
only building Debug or only building Release, only the IMPORTED_LOCATION
will be specified. If building debug_and_release, then IMPORTED_LOCATION
will refer to the Release location, and IMPORTED_LOCATION_DEBUG will refer
to the debug location.
https://codereview.qt-project.org/#change,26116
I'm looking for some review of the approach, and some confirmation of how
non-matching configurations are handled. Does it make sense?
In particular, with this set-up, how would a downstream create a
configuration which should use the debug libraries, but where they have
built Qt with debug_and_release (the default on Windows)? Would they have to
create another IMPORTED_LOCATION_Foo for all targets themselves?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Handling of Config specific imported targets?
On 05/16/2012 06:42 AM, Stephen Kelly wrote:
In Qt 5 we currently generate IMPORTED_LOCATION_${Config} for the Debug or
Release (or both, depending on platform), depending on how Qt is configured.
If both exist (on windows) and the caller uses CMAKE_BUILD_TYPE == Debug or
Release, the correct location should be used. However, this doesn't account
for having a different or empty CMAKE_BUILD_TYPE.
We already have some logic to account for a mismatch between the set of
valid configurations in the exporting v. importing project. See logic
here:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTarget.cxx;hb=v2.8.8#l4093
and these properties:
http://www.cmake.org/cmake/help/v2.8.8/cmake.html#prop_tgt:LOCATION_CONFIG
http://www.cmake.org/cmake/help/v2.8.8/cmake.html#prop_tgt:MAP_IMPORTED_CONFIG_CONFIG
CMake code should only ever *set* the IMPORTED_LOCATION properties.
If it wants to *get* the location it should use LOCATION_CONFIG.
CMake will follow the above approach to find a suitable match for
the requested CONFIG.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Review request: Ninja-EXPORT_COMPILE_COMMANDS
On Sun, May 13, 2012 at 11:59:20PM +0200, Stephen Kelly wrote: Stephen Kelly wrote: Furthermore, there is no need to make paths within the build directory absolute. Each command must be invoked from the home output directory (i.e. the build root directory), so each command's directory attribute should be set to that directory, rather than the start output directory as in your patch. Fixed now, If I understood you correctly. I've pushed this to the CMake stage repo now. Peter, could you verify that I should always use the same directory for the directory JSON property as I do in the patch? Yes, this looks fine now. Thanks, -- Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013231]: CPackDeb incorrectly leaks Debian dependencies across components
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13231
==
Reported By:Jess
Assigned To:
==
Project:CMake
Issue ID: 13231
Category: CPack
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-05-17 00:05 EDT
Last Modified: 2012-05-17 00:05 EDT
==
Summary:CPackDeb incorrectly leaks Debian dependencies
across components
Description:
Dependency generation in the Debian
control file using the CPACK_DEBIAN_PACKAGE_SHLIBS flag does not work correctly
for components. Dependencies
are generated, however each component is incorrectly
assigned all previously processed components' dependencies on top of
its own. This occurs regardless of whether the user explicitly
set any (additional) dependencies via CPACK_DEBIAN_PACKAGE_DEPENDS.
Steps to Reproduce:
3 components,
Comp1 has dependencies A, B, C, Comp3
Comp2 has dependencies D, E, F, Comp3
Comp3 has dependencies G
relevant config:
set(CPACK_COMPONENTS_IGNORE_GROUPS TRUE)
set(CPACK_DEB_COMPONENT_INSTALL TRUE)
set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS TRUE)
We have no way of expressing dependencies between components for the
purposes of Debian packaging (so far as I know) so Comp1 and Comp2 depending
on Comp3 is not achievable. That aside, if CMake processes Comp1 then Comp2,
then Comp3, the
resultant Debian package Comp1 will depend on A, B, C, package Comp2
(incorrectly)
on A, B, C, D, E, F and package Comp3 (incorrectly) on A, B, C, D, E, F,
G.
Additional Information:
To fix I patched the CPackDeb.cmake script as follows, introducing new
per-component user-defined dependency variable
CPACK_DEB_component_PACKAGE_DEPENDS, which should be used over
CPACK_DEBIAN_PACKAGE_DEPENDS if components are being used.
214,218c214,226
IF (CPACK_DEBIAN_PACKAGE_DEPENDS)
SET (CPACK_DEBIAN_PACKAGE_DEPENDS
${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS},
${CPACK_DEBIAN_PACKAGE_DEPENDS})
ELSE (CPACK_DEBIAN_PACKAGE_DEPENDS)
SET (CPACK_DEBIAN_PACKAGE_DEPENDS
${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS})
ENDIF (CPACK_DEBIAN_PACKAGE_DEPENDS)
---
IF(CPACK_DEB_PACKAGE_COMPONENT)
IF (CPACK_DEB_${CPACK_DEB_PACKAGE_COMPONENT}_PACKAGE_DEPENDS)
SET (CPACK_DEBIAN_PACKAGE_DEPENDS
${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS},
${CPACK_DEB_${CPACK_DEB_PACKAGE_COMPONENT}_PACKAGE_DEPENDS})
ELSE (CPACK_DEB_${CPACK_DEB_PACKAGE_COMPONENT}_PACKAGE_DEPENDS)
SET (CPACK_DEBIAN_PACKAGE_DEPENDS
${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS})
ENDIF (CPACK_DEB_${CPACK_DEB_PACKAGE_COMPONENT}_PACKAGE_DEPENDS)
ELSE (CPACK_DEB_PACKAGE_COMPONENT)
IF (CPACK_DEBIAN_PACKAGE_DEPENDS)
SET (CPACK_DEBIAN_PACKAGE_DEPENDS
${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS}, ${CPACK_DEBIAN_PACKAGE_DEPENDS})
ELSE (CPACK_DEBIAN_PACKAGE_DEPENDS)
SET (CPACK_DEBIAN_PACKAGE_DEPENDS
${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS})
ENDIF (CPACK_DEBIAN_PACKAGE_DEPENDS)
ENDIF (CPACK_DEB_PACKAGE_COMPONENT)
This config then will do the trick, also allowing 1 and 2's dependency
on 3 to be expressed:
set(CPACK_COMPONENTS_IGNORE_GROUPS TRUE)
set(CPACK_DEB_COMPONENT_INSTALL TRUE)
set(CPACK_DEB_1_PACKAGE_DEPENDS myproject-3)
set(CPACK_DEB_2_PACKAGE_DEPENDS myproject-3)
set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS TRUE)
==
Issue History
Date ModifiedUsername FieldChange
==
2012-05-17 00:05 Jess New Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
