Re: [CMake] multiple targets depending on generated file
Brad King wrote: Is this a bug in CMake? It seems there is enough information given that CMake could notice the dependency. But maybe it can't quite do it because its a separate directory? Maybe cmake can do the add_dependencies() automatically? This is expected. You need to do add_dependencies or use a separate custom target and then make both targets depend on that. CMake cannot just magically introduce an extra custom target or arbitrary dependency between existing targets. I checked the documentation for these: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:add_dependencies http://www.cmake.org/cmake/help/cmake-2-8- docs.html#command:set_source_files_properties It seems that the case I'm trying to solve would be far easier if it was possible to have file level dependencies in different directories. Is that feasible? It would be cool to have that dependency be internal. I'm using a macro wrapper similar to the one in the bug report, but sometimes I still get build failures due to the dbus xml stuff that I haven't tracked down and which are resolved on the next build. ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] multiple targets depending on generated file
Stephen Kelly wrote:
but sometimes I
still get build failures due to the dbus xml stuff that I haven't
tracked
down and which are resolved on the next build.
I think this is because I was missing some
add_dependencies(foo dbus_interfaces_xml)
in my app, so hopefully that's resolved for me now.
Nevertheless, if this can't be fixed in CMake, the fix should be
documented. The fix for the example in the bug report is attached.
diff --git a/CMakeLists.txt b/CMakeLists.txt
index c60bc16..633699e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -17,6 +17,10 @@ include(${QT_USE_FILE})
set( EXECUTABLE_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR} )
+add_custom_target(dbus_interfaces_xml ALL
+ COMMENT Helper target for XML stuff. The other apps and xml generations depend on it.
+)
+
add_subdirectory(master)
add_subdirectory(slave)
diff --git a/cmake/CustomMacros.cmake b/cmake/CustomMacros.cmake
new file mode 100644
index 000..3e0f8ca
--- /dev/null
+++ b/cmake/CustomMacros.cmake
@@ -0,0 +1,7 @@
+
+macro(my_generate_dbus_interface _header _customName )
+ qt4_generate_dbus_interface(${_header} ${_customName} ${ARGN} )
+ add_custom_target(xml_target_${_header} DEPENDS ${_customName})
+ add_dependencies(dbus_interfaces_xml xml_target_${_header} )
+endmacro()
+
diff --git a/master/CMakeLists.txt b/master/CMakeLists.txt
index f147a41..0b3ba2c 100644
--- a/master/CMakeLists.txt
+++ b/master/CMakeLists.txt
@@ -10,9 +10,11 @@ include_directories(
${PROJECT_BINARY_DIR}
)
+include(CustomMacros)
+
qt4_automoc(qml_dbus_master_moc_srcs ${qml_dbus_master_srcs})
-qt4_generate_dbus_interface(dynamicname.h ${CMAKE_BINARY_DIR}/com.kdab.DynamicName.xml)
+my_generate_dbus_interface(dynamicname.h ${CMAKE_BINARY_DIR}/com.kdab.DynamicName.xml)
qt4_add_dbus_adaptor(qml_dbus_master_srcs
${CMAKE_BINARY_DIR}/com.kdab.DynamicName.xml
@@ -27,3 +29,4 @@ target_link_libraries(master_app
${QT_QTDBUS_LIBRARIES}
)
+add_dependencies(master_app dbus_interfaces_xml)
diff --git a/slave/CMakeLists.txt b/slave/CMakeLists.txt
index c766563..c0e175d 100644
--- a/slave/CMakeLists.txt
+++ b/slave/CMakeLists.txt
@@ -24,3 +24,5 @@ target_link_libraries(slave_app
${QT_QTDECLARATIVE_LIBRARIES}
${QT_QTGUI_LIBRARIES}
)
+
+add_dependencies(slave_app dbus_interfaces_xml)
___
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Searchable mail archive
J.S. van Bethlehem wrote: Dear CMake users, This week I started to investigate possibilities to move my build-system over to CMake after hearing a lot of good stories about it. To be honest, so far I'm still not quite convinced. The learning (I find at least) is rather steep and the documentation rather sparse (afaics) Then I noticed this mailing list, which would obviously be a got source to look for help, if it were searchable - so that's my question: is there some mirror of the mail-archive where I can search through passed mails to the list? http://news.gmane.org/gmane.comp.programming.tools.cmake.user ___ 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://www.cmake.org/mailman/listinfo/cmake
[CMake] GenerateExportHeader macrr for CMake?
Hi, I came up with an idea to simplify the creation of export headers for hidden visibility by using configure_file. After implementing it I saw that the idea has come up before :) http://www.mail-archive.com/cmake@cmake.org/msg27058.html Please see the attached proof of concept. Could we get something like GenerateExportHeader.cmake and exportheader.cmake.in into CMake 2.8? Alex tells me I'd have to maintain it, respond to bugs, and keep source compatibility, so I guess I can say I'll do that :). I know there are other special cases for other compilers, but I thought I'd put the implementation of the concrete idea here for discussion at this point. Thanks, Steve. cmake_generate_export.tar.gz Description: application/compressed-tar ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] GenerateExportHeader macrr for CMake?
Hendrik Sattler wrote: Really why? There is no dynamic content in such a header file. I'm not sure what you mean? Could you be more specific? ___ 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://www.cmake.org/mailman/listinfo/cmake
[CMake] Where is QT_USE_IMPORTED_TARGETS not safe to use?
Hi, The FindQt4 module has this to say about QT_USE_IMPORTED_TARGETS: If QT_USE_IMPORTED_TARGETS is enabled, the QT_QTFOO_LIBRARY variables are set to point at these imported targets. This works better in general, and is also in almost all cases fully backward compatible. The only issue is when a project A which had this enabled then exports its libraries via export or EXPORT_LIBRARY_DEPENDENCIES(). In this case the libraries from project A will depend on the imported Qt targets, and the names of these imported targets will be stored in the dependency files on disk. The part that is not clear to me is this: This means when a project B then uses project A, these imported targets must be created again, otherwise e.g. Qt4__QtCore will be interpreted as name of a library file on disk, and not as a target, and linking will fail. What does it mean to say that the imported targets must be created again? Is it a source incompatibility? Does it mean that my downstreams have to use QT_USE_IMPORTED_TARGETS if I do? The KDE techbase page has additional caveats such as checking for file endings of the libraries etc I guess. I don't do such things in Grantlee, but if the use of QT_USE_IMPORTED_TARGETS affects downstreams too (as above) it might be relevant. http://techbase.kde.org/Development/CMake_KDE_4_4#FindQt4.cmake:_Imported_Targets_for_the_libraries Would using the variable have any real benefit? I have the following in my CMakeLists which I suspect may be removable if I use the variable: # http://mail.kde.org/pipermail/kde-windows/2007-December/001692.html # http://lists.trolltech.com/pipermail/qt-interest/2009-July/009829.html # qt is always compiled with QT_NO_DEBUG under mingw, # so we need to compile stuff linked against it # the same or otherwise QPluginLoader rejects plugins add_definitions(-DQT_NO_DEBUG) 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Where is QT_USE_IMPORTED_TARGETS not safe to use?
Hi,
Thanks for the response. I've got a few followups.
Clinton Stimpson wrote:
The part that is not clear to me is this:
This
means when a project B then uses project A, these imported targets must
be created again, otherwise e.g. Qt4__QtCore will be interpreted as
name of a library file on disk, and not as a target, and linking will
fail.
What does it mean to say that the imported targets must be created again?
Is it a source incompatibility? Does it mean that my downstreams have to
use QT_USE_IMPORTED_TARGETS if I do?
That applies if you use the install(EXPORT) command to create imported
targets
of the Grantlee libraries. That cmake generated file could then be
included in
your GrantleeConfig.cmake.
Yes, I am currently using install(EXPORT) already. The GrantleeTargets file
is included in the GrantleeConfig file.
If you used QT_USE_IMPORTED_TARGETS, it would
contain the imported target names in that cmake generated export file,
otherwise it would contain full paths to Qt libraries on your system.
Yes, with the option enabled the GrantleeTargets-debug contains
IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG Qt4::QtCore
and without it contains
IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG /usr/lib/libQtCore.so
However, somehow I don't think you understood what I was really asking, so
I'll try again. What I don't understand is the comment about imported
targets must be created again. Initially I thought the comment was saying
that a downstream from Grantlee would have to do something 'again' after
Grantlee did it 'first', and I was wondering what the 'something' is. Now I
think maybe the comment may only be about generating the GrantleeTargets-
debug file again (at build time) to use the target instead of the path, and
linking will fail until that is done.
Is that correct?
The GrantleeConfig.cmake could set QT_USE_IMPORTED_TARGETS and a
find_package(Qt4) to recreated those imported targets.
Ok, so maybe setting QT_USE_IMPORTED_TARGETS is the thing that needs to be
done 'again' by project B?
So that means that yes, downstreams have to use QT_USE_IMPORTED_TARGETS if I
do and can't use the path to the Qt libraries. From the Grantlee point of
view the path to the libraries are not important, but it's relevant if it
prevents downstreams from being able to use them.
Would using the variable have any real benefit?
If you used install(EXPORT), the benefit would be that cmake would take
care of the dependencies for you, and it would not have the full paths to
libraries (if that matters to your users).
In what way does CMake take care of the dependencies for me?
Do you mean that it takes care of automatically linking to the dependencies
so that downstreams can do:
target_link_libraries(myApp
${Grantlee_CORE_LIBRARIES}
)
instead of
target_link_libraries(myApp
${Grantlee_TEMPLATES_LIBRARIES}
${QT_QTCORE_LIBRARIES}
)
for example? Or do you mean something different?
I have the following in my
CMakeLists which I suspect may be removable if I use the variable:
# http://mail.kde.org/pipermail/kde-windows/2007-December/001692.html
#
http://lists.trolltech.com/pipermail/qt-interest/2009-July/009829.html #
qt is always compiled with QT_NO_DEBUG under mingw,
# so we need to compile stuff linked against it
# the same or otherwise QPluginLoader rejects plugins
add_definitions(-DQT_NO_DEBUG)
That is unrelated to imported targets.
There is currently no mechanism in CMake to have the FindQt4.cmake module
handle QT_DEBUG/QT_NO_DEBUG preprocessor defines automatically.
One does not have this problem if the QT_USE_FILE is used. Otherwise you
may do what it does for your project to add the configuration dependent Qt
preprocessor defines.
Hmm, I do use the QT_USE_FILE. I recently attempted to remove that
add_definitions call and something failed (maybe it was plugin loading at
runtime - I don't remember). I'll try again now and see if I can say what
the problem is.
Thanks for answers and patience. I tend to dislike magic, so I want to
understand all of this stuff before I actually apply it.
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://www.cmake.org/mailman/listinfo/cmake
[CMake] Build flags when using Qt plugins (was: Where is QT_USE_IMPORTED_TARGETS not safe to use?)
Clinton Stimpson wrote:
#
http://mail.kde.org/pipermail/kde-windows/2007-December/001692.html
#
http://lists.trolltech.com/pipermail/qt-interest/2009-July/009829.html
# qt is always compiled with QT_NO_DEBUG under mingw,
# so we need to compile stuff linked against it
# the same or otherwise QPluginLoader rejects plugins
add_definitions(-DQT_NO_DEBUG)
That is unrelated to imported targets.
There is currently no mechanism in CMake to have the FindQt4.cmake
module handle QT_DEBUG/QT_NO_DEBUG preprocessor defines automatically.
One does not have this problem if the QT_USE_FILE is used. Otherwise
you may do what it does for your project to add the configuration
dependent Qt preprocessor defines.
Hmm, I do use the QT_USE_FILE. I recently attempted to remove that
add_definitions call and something failed (maybe it was plugin loading at
runtime - I don't remember). I'll try again now and see if I can say what
the problem is.
Ok.
I applied this patch:
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 3746e4f..2630f53 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -39,7 +39,7 @@ if (CMAKE_COMPILER_IS_GNUCXX)
# qt is always compiled with QT_NO_DEBUG under mingw,
# so we need to compile stuff linked against it
# the same or otherwise QPluginLoader rejects plugins
-add_definitions(-DQT_NO_DEBUG)
+#add_definitions(-DQT_NO_DEBUG)
endif ()
endif()
diff --git a/cmake/modules/GrantleeUse.cmake
b/cmake/modules/GrantleeUse.cmake
index 472b45a..a3cff0b 100644
--- a/cmake/modules/GrantleeUse.cmake
+++ b/cmake/modules/GrantleeUse.cmake
@@ -60,5 +60,5 @@ if (MINGW)
# qt is always compiled with QT_NO_DEBUG under mingw,
# so we need to compile stuff linked against it
# the same or otherwise QPluginLoader rejects plugins
- add_definitions(-DQT_NO_DEBUG)
+ #add_definitions(-DQT_NO_DEBUG)
endif ()
diff --git a/templates/lib/pluginpointer_p.h
b/templates/lib/pluginpointer_p.h
index 11974dd..cfcd4d5 100644
--- a/templates/lib/pluginpointer_p.h
+++ b/templates/lib/pluginpointer_p.h
@@ -23,6 +23,7 @@
#include QtCore/QPluginLoader
#include QtCore/QSharedPointer
+#include QtCore/QDebug
On windows my cmake version is 2.8.4 and my Qt version is 4.6.2
namespace Grantlee
{
@@ -62,6 +63,7 @@ public:
m_pluginLoader = QSharedPointerQPluginLoader( new
QPluginLoader( fileName ), _deleter );
m_object = m_pluginLoader-instance();
+qDebug() Object m_object m_pluginLoader-errorString();
if ( !m_object )
return;
And all unit tests then fail with MinGW. The errorString() reported is:
QDEBUG : TestBuiltinSyntax::testInsignificantWhitespace(insignificant-
whitespace43) Object QObject(0x0) The plugin
'C:/software/grantlee/qtcreator-build/grantlee/0.1/grantlee_defaulttags.dll'
uses incompatible Qt library. (Cannot mix debug and release libraries.)
Is this unexpected? I'm not familiar enough with windows tools to inspect
the binaries and see what's going on. Any help appreciated.
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Where is QT_USE_IMPORTED_TARGETS not safe to use?
Clinton Stimpson wrote: It means the target must be created again with something like add_library(Qt4::QtCore UNKNOWN IMPORTED) If GrantleeConfig.cmake were to do this: SET(QT_USE_IMPORTED_TARGETS 1) find_package(Qt4 REQUIRED) then the imported targets would satisfy the Qt4::QtCore reference and others from your GrantleeTargets-debug. The GrantleeConfig.cmake could set QT_USE_IMPORTED_TARGETS and a find_package(Qt4) to recreated those imported targets. Ok, so maybe setting cis the thing that needs to be done 'again' by project B? Yes, or preferably in your GrantleeConfig.cmake so project B doesn't have to do it. I tried creating the error scenario, but it does work even if the downstream does not set QT_USE_IMPORTED_TARGETS and even if I don't put it in GrantleeConfig either. Qt4::QtCore is never interpreted as a file path because FindQt4.cmake sets it unconditionally, and only conditionally sets QT_QTCORE_LIBRARY to Qt4::QtCore based on QT_USE_IMPORTED_TARGETS. That means that if Grantlee uses ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Where is QT_USE_IMPORTED_TARGETS not safe to use?
Wups, sent a moment to early... Stephen Kelly wrote: Clinton Stimpson wrote: It means the target must be created again with something like add_library(Qt4::QtCore UNKNOWN IMPORTED) If GrantleeConfig.cmake were to do this: SET(QT_USE_IMPORTED_TARGETS 1) find_package(Qt4 REQUIRED) then the imported targets would satisfy the Qt4::QtCore reference and others from your GrantleeTargets-debug. The GrantleeConfig.cmake could set QT_USE_IMPORTED_TARGETS and a find_package(Qt4) to recreated those imported targets. Ok, so maybe setting cis the thing that needs to be done 'again' by project B? Yes, or preferably in your GrantleeConfig.cmake so project B doesn't have to do it. I tried creating the error scenario, but it does work even if the downstream does not set QT_USE_IMPORTED_TARGETS and even if I don't put it in GrantleeConfig either. Qt4::QtCore is never interpreted as a file path because FindQt4.cmake sets it unconditionally, and only conditionally sets QT_QTCORE_LIBRARY to Qt4::QtCore based on QT_USE_IMPORTED_TARGETS. That means that if GrantleeTarget-debug uses IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG Qt4::QtCore then the Qt4::QtCore will never be interpreted as a file on disk and the comment in the file: This means when a project B then uses project A, these imported targets must be created again, otherwise e.g. Qt4__QtCore will be interpreted as name of a library file on disk, and not as a target, and linking will fail. is not correct. Right? Also, it means that I don't have to use SET(QT_USE_IMPORTED_TARGETS 1) find_package(Qt4 REQUIRED) in my GrantleeConfig? 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://www.cmake.org/mailman/listinfo/cmake
[CMake] How to handle COMPONENT arguments to find_package in my Config file?
Hi,
In my GrantleeConfigVersion.cmake.in I can use ${PACKAGE_FIND_VERSION} which
I presume is filled from the find_package command (I just copied the file
from elsewhere).
Is there an equivalent for COMPONENTS so that if someone does a
find_package(Grantlee COMPONENTS Foo Bar)
my config file would do something like:
if (${PACKAGE_FIND_COMPONENTS} CONTAINS Foo)
# Find the dependencies of Foo
endif()
if (${PACKAGE_FIND_COMPONENTS} CONTAINS Bar)
# Find the dependencies of Bar
endif()
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to handle COMPONENT arguments to find_package in my Config file?
Alexander Neundorf wrote:
On Wednesday 22 June 2011, Stephen Kelly wrote:
Hi,
In my GrantleeConfigVersion.cmake.in I can use ${PACKAGE_FIND_VERSION}
which I presume is filled from the find_package command (I just copied
the file from elsewhere).
Is there an equivalent for COMPONENTS so that if someone does a
Beside the find_package() documentation in the cmake man page, those stuff
is documented in the readme.txt in the CMake module directory.
Hmm, I didn't find it in the output of cmake --help-command find_package,
but you're right that it's in the readme.txt file. Thanks for the pointer.
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to handle COMPONENT arguments to find_package in my Config file?
Clinton Stimpson wrote:
On Wednesday, June 22, 2011 10:01:37 am Stephen Kelly wrote:
Hi,
In my GrantleeConfigVersion.cmake.in I can use ${PACKAGE_FIND_VERSION}
which I presume is filled from the find_package command (I just copied
the file from elsewhere).
Is there an equivalent for COMPONENTS so that if someone does a
find_package(Grantlee COMPONENTS Foo Bar)
my config file would do something like:
if (${PACKAGE_FIND_COMPONENTS} CONTAINS Foo)
# Find the dependencies of Foo
endif()
if (${PACKAGE_FIND_COMPONENTS} CONTAINS Bar)
# Find the dependencies of Bar
endif()
You can use Grantlee_FIND_COMPONENTS which would contain the components
passed in by the user.
Here's an example of using it:
...
# the Grantlee exports file to accompany this config auto generated by
# cmake's export() if this config is used in the build tree,
# or install(EXPORT ...) if used in the installation tree
SET(GrantleeExportsFile @GrantleeExportsFile@)
...
include(${GrantleeExportsFile})
# check that the user requested components
# are actually targets that are part of this build
IF( Grantlee_FIND_COMPONENTS )
FOREACH(comp ${Grantlee_FIND_COMPONENTS})
if(NOT TARGET ${comp})
SET(Grantlee_${comp}_FOUND 0)
IF(Grantlee_FIND_REQUIRED_${comp})
MESSAGE(FATAL_ERROR Grantlee ${comp} not available.)
ENDIF()
ELSE()
SET(Grantlee_${comp}_FOUND 1)
ENDIF()
ENDFOREACH()
ENDIF()
Thanks, this looks like what I need alright.
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Where is QT_USE_IMPORTED_TARGETS not safe to use?
Hi Alex, thanks for the more detailed explanation. It is indeed more clear.
However, I still don't think there is a linker error if I omit
QT_USE_IMPORTED_TARGETS from the config file. I tried to re-create the error
condition with a trivial project and could not re-create it.
Alexander Neundorf wrote:
IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG Qt4::QtCore
The statement above has the effect than when a user of Grantlee in a his
project named Foo links against the Grantlee library, it will additionally
link against Qt4::QtCore.
If there is no target (imported or normal, this doesn't matter) with
that name in the project Foo, then Qt4::QtCore is considered a direct
parameter for the linker and cmake will append (under Linux) a
-lQt4::QtCore to the linker command line.
Which would be wrong.
So for that to work correctly, an imported target with the name
Qt4::QtCore must be created somewhere in the project Foo.
Typically by FindQt4, which should then create these imported targets.
Qt4::QtCore seems to be defined as an import unconditionally in FindQt4.
Well, almost uncondiditionally. qmake has to be found, and it has to be
either debug or release mode, but it doesn't look like FindQt4 is very
useful if either case is false anyway.
So this works just fine:
$ cat CMakeLists.txt main.cpp
cmake_minimum_required(VERSION 2.8)
project(cmdline)
find_package(Qt4 REQUIRED QtCore )
INCLUDE_DIRECTORIES(${QT_INCLUDE_DIR})
add_executable(cmdline
main.cpp
)
target_link_libraries(cmdline
Qt4::QtCore
)
#include QtCore/QCoreApplication
int main(int argc, char **argv)
{
QCoreApplication app(argc, argv);
return app.exec();
}
That example seems to indicate to me that even if using
set(QT_USE_IMPORTED_TARGETS 1) in the Config file is the right thing to do
and I should do it anyway, it won't cause a linker error if I leave it out.
Is there some way I can modify that example to re-create the linker error
described in the comment?
You can still test in e.g. GrantleeConfig.cmake whether the target
Qt4::QtCore exists and fail with FATAL_ERROR if it doesn't.
I strongly recommend using these imported targets, one reason is because
otherwise when installing a binary package of Grantlee under Windows, it
will not be possible to freely choose the install location, or better the
location where Qt must be is then already hardcoded in
GrantLeeConfig.cmake (because then there won't be Qt4::QtCore in
GrantleeConfig.cmake, but something like
c:/where/was/Qt/at/buildtime/QtCore.dll). When then linking against
Grantleee, and Qt is installed somewhere else, it will fail.
Yes, this makes sense. I think that's something we almost covered in the
review in Randa :). I am adding the setter to use the imported target
feature so it will be in the next release, but I also want to understand it
fully.
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Where is QT_USE_IMPORTED_TARGETS not safe to use?
Clinton Stimpson wrote: Yeah, I just looked again to verify what you are seeing... you don't need to do this SET(QT_USE_IMPORTED_TARGETS 1) in GrantleeConfig.cmake, but you can still do find_package(Qt4 REQUIRED) to create the imported targets. Clint Cool, I'll just do a find_package(Qt4 REQUIRED) in the config file for now then. Thanks for the help, 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Build flags when using Qt plugins (was: Where is QT_USE_IMPORTED_TARGETS not safe to use?)
Clinton Stimpson wrote: And all unit tests then fail with MinGW. The errorString() reported is: QDEBUG : TestBuiltinSyntax::testInsignificantWhitespace(insignificant- whitespace43) Object QObject(0x0) The plugin 'C:/software/grantlee/qtcreator- build/grantlee/0.1/grantlee_defaulttags.dll ' uses incompatible Qt library. (Cannot mix debug and release libraries.) Is this unexpected? I'm not familiar enough with windows tools to inspect the binaries and see what's going on. Any help appreciated. Do you have a way to check the actual compile flags used to build the code? Clint I did two clean builds with cmake .. -G MinGW Makefiles mingw32-make VERBOSE=1 The output is attached, but I'm not certain it's very helpful. Let me know if anything else would be useful. I can maybe try to create a smaller plugin using qt example for easy reproduction of the issue. Thanks, Steve. grantleemingwoutput.tar.gz Description: application/compressed-tar ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Build flags when using Qt plugins (was: Where is QT_USE_IMPORTED_TARGETS not safe to use?)
Clinton Stimpson wrote: The output is attached, but I'm not certain it's very helpful. Let me know if anything else would be useful. I can maybe try to create a smaller plugin using qt example for easy reproduction of the issue. What is CMAKE_BUILD_TYPE set to? I think it should be the default. Will have to check (no windows VM, will have to reboot). ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Build flags when using Qt plugins (was: Where is QT_USE_IMPORTED_TARGETS not safe to use?)
Clinton Stimpson wrote: On Wednesday, June 22, 2011 01:47:33 pm Stephen Kelly wrote: Clinton Stimpson wrote: The output is attached, but I'm not certain it's very helpful. Let me know if anything else would be useful. I can maybe try to create a smaller plugin using qt example for easy reproduction of the issue. Also the files in templates/lib are not compiled with flags from QT_USE_FILE. You can tell that by whether files are compiled with -DQT_CORE_LIB. Good catch. I'll remedy that and re-try. In the mean-time I have created a CMake build system for the Qt echoplugin example. On my setup it fails to load the plugin at runtime unless I comment out the add_definition(-DQT_NO_DEBUG). Could you try the same? That would at least show that it's a problem on my end. I tried the example, and if I use mingw, I have to set CMAKE_BUILD_TYPE to something for the example to work. If I use nmake or visual studio, CMAKE_BUILD_TYPE is defaulted to Debug, so it just works. So it seems one should fix the Platform/Windows-GNU.cmake or something to have something like a SET(CMAKE_BUILD_TYPE_INIT Release) or SET(CMAKE_BUILD_TYPE_INIT Debug) Would you like to submit a bug for this? Thanks for looking into it. Submitted as http://public.kitware.com/Bug/view.php?id=12301 As a workaround, you can enforce a value for CMAKE_BUILD_TYPE if on Windows and CMAKE_CONFIGURATION_TYPES is empty. If you enforce that, then you don't need to have the add_definition(-DQT_NO_DEBUG). Thanks for the pointer. I'll try setting that in the cache before calling project() as described here: http://www.cmake.org/pipermail/cmake/2008-September/023808.html All the best, 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Build flags when using Qt plugins (was: Where is QT_USE_IMPORTED_TARGETS not safe to use?)
Stephen Kelly wrote: As a workaround, you can enforce a value for CMAKE_BUILD_TYPE if on Windows and CMAKE_CONFIGURATION_TYPES is empty. If you enforce that, then you don't need to have the add_definition(-DQT_NO_DEBUG). Thanks for the pointer. I'll try setting that in the cache before calling project() as described here: http://www.cmake.org/pipermail/cmake/2008-September/023808.html It didn't really work as described. I had to set the CMAKE_BUILD_TYPE after the call to project() or else MINGW seemed to not be defined, and I had to use if (NOT CMAKE_BUILD_TYPE) instead of if (NOT DEFINED CMAKE_BUILD_TYPE). I don't know if either of these things are themselves bugs or expected behaviour. if (MINGW) if(NOT CMAKE_BUILD_TYPE) set(CMAKE_BUILD_TYPE Debug CACHE STRING Choose the type of build, options are: None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel Coverage.) endif() endif() I'm happy to have this working now though :). I confirmed that changing it in cmake-gui works too. 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://www.cmake.org/mailman/listinfo/cmake
[CMake] Can I determine what a target is in a macro?
Hi,
I'd like to be able to write a macro like this:
macro(my_macro SOME_TARGET)
if (isStaticLibraryTarget(${SOME_TARGET})
message(FATAL This macro can only be used with shared libraries)
endif()
endmacro()
add_library(libshared SHARED shared.cpp)
my_macro(libshared) # Works
add_library(libstatic static.cpp)
my_macro(libstatic) # Fatal
Is it possible to whether a target library is shared or static in a macro?
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can I determine what a target is in a macro?
David Cole wrote:
The target property TYPE tells you what the type of the library is:
http://cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:TYPE
Use:
get_property(type TARGET ${SOME_TARGET} PROPERTY TYPE)
message(type='${type}')
to retrieve the value of the TYPE property.
http://cmake.org/cmake/help/cmake-2-8-docs.html#command:get_property
HTH,
David
Just what I was looking for, thanks.
___
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Install optional targets
Tim Gallagher wrote: Hi, I asked about this awhile back and haven't had any luck with it, so I'll try again. What we are trying to do is have a project (called Utilities) that has a bunch of targets (the actual utility executables). Let's say there are 4 utils: pre, post, grid, and restart. We would like to do something like: make pre make post make install snip Any suggestions? KDE uses macro_optional_add_subdirectory(grid) for this. http://quickgit.kde.org/index.php?p=extra-cmake- modules.gita=blobh=e1733bcce714c216bd253420ea0a37f5bd1ba68bhb=f0937a4fe5db2ab7f566110876d2984779f33a3ef=modules/ECMOptionalAddSubdirectory.cmake According to the notes http://community.kde.org/KDE_Core/Platform_11/Buildsystem/FindFilesSurvey this won't be accepted into CMake. If you like that idea better than what you currently have you can copy the file. We'll be making releases of extra- cmake-modules eventually. All the best, 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Converting QMake project to CMake
NoRulez wrote: Hi, i'm trying to convert a qmake project to CMake. How can i translate CONFIG to CMake or what is the CMake's way of using the CONFIG variable? e.g. CONFIG += mylib Is this the CMake equivalent: SET(mylib TRUE) No, probably not. What does CONFIG += mylib do for a third party lib? This link says CONFIG only accepts values with internal meaning to qmake: http://doc.qt.nokia.com/latest/qmake-variable-reference.html#config 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] debug/optimized include directories
David Cole wrote: On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey rcdai...@gmail.com wrote: On Tue, Nov 1, 2011 at 3:32 PM, David Cole david.c...@kitware.com wrote: Not yet Meaning there are plans in the works to add such functionality in the near future? For now I guess I could actually hard code VS environment variables in my include directory strings, such as $(Configuration). There is a feature planned to add per-target include directories (as a target property). As part of that work, we will probably naturally also add per-configuration values of that new target property. It is not yet added as a feature request in the bug tracker, but there are related ones that I may borrow for the purpose. Stay tuned for more info, but it is not coming in the next week or two. Hopefully, in time for 2.8.7, but it depends on timing at this point so no promises. Hi David, I'm interested in this feature. I'd like to get it into CMake 2.8.7. It came up in the recent thread about how Qt5Config.cmake should work: http://thread.gmane.org/gmane.comp.lib.qt.project.devel/79/focus=226 You mentioned that there are some side-line relevant bugs in the CMake tracker for this. Could you point me to them? Could you also indicate the approximate location in the code to look to for starting to work on this (cmTarget.cxx?). 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Don't export symbols but the one I want
David Demelier wrote: Hello, I'm creating a library that use a lot of internal code (not static because it should be visible by other compilation units) so I would like to don't export any symbols but only the one I want. Usually you use __declspec(dllexport) for windows but on unix and gcc everything is exported and I don't know any portable way to disable this. Does CMake can handle this problem and export some symbols without using ten thousand of #ifdef #endif in C files? Cheers, See also cmake --help-command GenerateExportHeader in cmake 2.8.6. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake + Ninja
Hi, I didn't time it, but I was able to use ninja with kdelibs and grantlee (my smaller Qt project). Clifford Yapp wrote: In case anybody else wants to give ninja a spin, here's what I did to test it (using bash as a shell): git clone git://github.com/martine/ninja.git git clone -b ninja-generator-pr git://github.com/pcc/CMake.git If you already have a CMake clone, then instead of the above do this: git remote add ninja git://github.com/pcc/CMake.git git checkout ninja-generator-pr I'm trying to decide whether I like the less wordy output compared to make, and I think I prefer ninjas output. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [New Module] Arduino CMake
Alfa Omega wrote: Hi everyone, I'm not quite sure what the correct procedure is for becoming a CMake contributor, but from what I've read I should send a email here if I want to add a new module to cmake. Hi Tomasz, This page should have all you need to know: http://www.itk.org/Wiki/CMake:Module_Maintainers It's probably more appropriate to email the developers list: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers Thanks, Steve. For the past year I've been hosting my CMake modules on GitHub ( https://github.com/queezythegreat/arduino-cmake) and the project is mature enough that it could be included into CMake. The project is called Arduino CMake and it adds support for building Arduino projects. It is a alternative to the Arduino IDE, and works on Windows, Linux and Mac. The project is growing and getting more and more users, and I think it's would be a god fit to start bundling it with CMake. The project is well documented both from a developer standpoint as well as the user side. So what are the steps I should take in order to integrate my project into CMake? I also would like to contribute back some extensions to the CMake, such as Teamcity support for CTest. Any information would be greatly appreciated. Tomasz Bogdal -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug fix requests for the *next* release of CMake...
David Cole wrote: Replies requested. Short replies only. Read on. Just a short reply with bug numbers or links to the bugs is all we need here. Please move specific discussions into the bugs themselves or start a new thread to talk about it... Replies on this thread should just be a collector for bug numbers. http://public.kitware.com/Bug/view.php?id=12588 Discussion: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2285/focus=2299 Thanks, -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Code and API review request for Qt5 CMake files
Just forwarding to the cmake users list.
Stephen Kelly wrote:
Hi there,
Qt5 generates its own CMake files, which you will be able to use to find
Qt5 and build with it.
That is, you will port from, eg
find_package(Qt4 REQUIRED Core Gui Xml)
to
find_package(Qt5Widgets REQUIRED)
find_package(Qt5Xml REQUIRED)
find_package(Qt5Core) is also possible but is not needed because it is a
dependency of at least one of the other requirements already in this case.
find_package(Qt5) will not work currently (though it can be made to work
now or after Qt 5.0).
You will then port
target_link_libraries(foo ${QT_QTCORE_LIBRARIES})
to
target_link_libraries(foo ${Qt5Core_LIBRARIES})
etc.
Or you might use qt5_use_package:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3083
qt5_use_package(foo Core)
# That's it! Nothing more to do.
The variables all map fairly well. There is also a Qt5Transitional package
which might help with that (If it gets released, which I'm not certain it
will be): https://projects.kde.org/projects/kdesupport/extra-cmake-
modules/repository/revisions/master/entry/modules/FindQt5Transitional.cmake
The Qt5moduleConfig.cmake files are generated and installed by Qt
itself.
I'd like a review of them by people familiar enough with how CMake works
and an API review from people familiar with how it is used.
The generation of them is platform specific, and configure options
specific, eg whether you use -framework on mac, whether you use MinGW or
MSVC, whether building with an infix or a namespace. The easiest way for
you to generate the config files is:
# Note: Don't bother cloning qt5.git unless you already have it.
# That takes forever.
git clone git://gitorious.org/qt/qtbase.git
cd qtbase
./configure
ls lib/cmake
Make sure you have at least commit
c470999329ee576038c50573314699f972f48909.
You can go on to build and test them if you wish. The ctest unit tests are
in qtbase/tests/manual/cmake. These tests are not part of any
multi-platform CI system.
Compared to the last time I emailed about this, the generated Config files
have become more simple. I discovered that qmake can have conditionals in
its configure_file equivalent.
Things that work:
* Finding Qt with an infix.
* Building against Qt with a namespace.
* Finding statically built Qt (though when linking you have to list the
dependencies yourself currently)
* Finding a particular version should work as ConfigVersion files are
installed, but I have not tested it.
Things to review:
* Are the Config files created correctly for your platform and
configuration?
* Do the unit tests pass on your platform?
* Currently there is no Qt5Config.cmake.
Such a thing could probably exist and use the FIND_COMPONENTS to find what
was requested. However, because there is no way to signal from a Config
file that a component was not found (that is, find_package(Qt5 REQUIRED
Gui Xml) might not find QtXml, but Qt5_FOUND would still be true if the
Qt5Config file is found, whether the component is or not), I'm not sure
it's a good idea, or at least it's more complicated. At least, I think
something like qt5_use_package is a better idea anyway.
We could have a small FindQt5.cmake in CMake which could do that however
maybe.
* Do you see any issues related to cross compiling?
* Try my port of the CMake Gui dialog to Qt5, or review the patches (most
of the patches make sense in CMake master anyway IMO):
https://gitorious.org/~steveire/cmake/steveires-cmake/commits/qt5-port
* API Review -
Do the variable names make sense? For example, to find a regular Qt5Gui,
you use find_package(Qt5Gui) and then you can use ${Qt5Gui_LIBRARIES}.
To find a Qt which was built with a namespace you use find_package(Qt5Gui)
and then you can use ${Qt5Gui_LIBRARIES}. That is - it's exactly the same.
To find a Qt that was built with an infix in the library names, you use
find_package(Qt5Gui) and then you can use ${Qt5Gui_LIBRARIES}. That is -
it's exactly the same.
Is there any reason for it not to be the exact same in all these cases?
I'd imagine if using an infix-ed Qt, that's an implementation detail. If
using a namespaced Qt, it might be an uninteresting implementation detail.
I'm not really certain of the use-cases for a namespaced Qt and how that
might affect this CMake API.
* Is anything missing? One thing that is missing is the qt4_automoc macro
(all other macros are available with qt5 equivalents). Alex say's it's
broken. The CMAKE_AUTOMOC feature is a not-completely-source-compatible
replacement.
Thanks,
--
Stephen Kelly stephen.ke...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
--
Powered by www.kitware.com
Visit other Kitware
[CMake] What does find_package(COMPONENTS) do? and
Hi,
The documentation says
A package-specific list of components may be listed after the REQUIRED
option or after the COMPONENTS option if no REQUIRED option is given.
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_package
But it doesn't say why you would want to do that. At first I thought it was
to specify that only the components specified would be used to fill cmake
variables. However, find_package(Qt COMPONENTS QtCore) also results in
${QT_QTGUI_LIBRARY} being defined for example. So then I thought maybe the
semantic is that if one of the components can not be found, the find_package
fails. So I tried find_package(Qt REQUIRED QtCore QtDoesNotExist) which
works without error.
What am I missing?
The reason I ask is that I finally figured out why the tests in my library
needed to be linked to QtGui, even though it only uses QtCore.
The reason is that find_package(Qt) causes QT_GUI_LIB to be defined. Which
in turn causes QTEST_MAIN to be defined to expand to use QApplication
instead of QCoreApplication as it is if QT_GUI_LIB is not defined.
http://qt.gitorious.org/qt/qt/blobs/4.7/src/testlib/qtest.h
find_package(Qt REQUIRED QtCore QtScript) does not cause QT_GUI_LIB to be
defined. However, some of my targets do need QtGui, so I should specify it,
right?
So if I do specify it I'll end up having QT_GUI_LIB defined when building my
unit tests. I could remove_definitions(-DQT_GUI_LIB), but apart from being a
BadHack(tm), it causes my unit tests which *do* require QtGui to fail at
runtime because they create QWidgets and by undeffing QT_GUI_LIB I build
them to use QCoreApplication instead of QApplication (Not allowed in Qt), so
the tests fail at runtime.
http://gitorious.org/grantlee/grantlee/blobs/0.1/tests/CMakeLists.txt
Is there a solution to all this? What is the point of COMPONENTS if it has
no effect on what I can include or link to? Is it possible to link some of
my tests to QtGui but not all of them and still have them all pass? Do I
need to just link my core tests to QtGui and use QApplication and quit my
complaining?
The only way I can see to satisfy all requirements is attached. Is that
acceptable or is there a better way?
All the best,
Steve.
diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
index aef989e..8709213 100644
--- a/tests/CMakeLists.txt
+++ b/tests/CMakeLists.txt
@@ -17,6 +17,8 @@ configure_file(grantlee_paths.h.cmake ${PROJECT_BINARY_DIR}/grantlee_paths.h)
set (_rcc_file scriptedtags.qrc)
qt4_add_resources(_scripted_rcc_src ${_rcc_file} OPTIONS -root /plugins/grantlee/${Grantlee_MAJOR_MINOR_VERSION_STRING} )
+remove_definitions(-DQT_GUI_LIB)
+
macro(GRANTLEE_CORE_UNIT_TESTS)
foreach(_testname ${ARGN})
set(_testSrcs ${_testname}.cpp)
@@ -24,13 +26,14 @@ macro(GRANTLEE_CORE_UNIT_TESTS)
qt4_generate_moc(${_testname}.cpp ${moc_output_file})
add_executable(${_testname}_exec ${_testSrcs} ${moc_output_file} ${_scripted_rcc_src} ${CMAKE_SOURCE_DIR}/corelib/lexer.cpp)
add_test(${_testname} ${_testname}_exec )
-target_link_libraries(${_testname}_exec ${QT_QTTEST_LIBRARY} ${QT_QTGUI_LIBRARY} ${Grantlee_CORE_LIBRARIES} )
+target_link_libraries(${_testname}_exec ${QT_QTTEST_LIBRARY} ${Grantlee_CORE_LIBRARIES} )
endforeach(_testname)
endmacro(GRANTLEE_CORE_UNIT_TESTS)
macro(GRANTLEE_GUI_UNIT_TESTS)
foreach(_testname ${ARGN})
set(_testSrcs ${_testname}.cpp)
+set_source_files_properties(${_testSrcs} PROPERTIES COMPILE_FLAGS -DQT_GUI_LIB )
set(moc_output_file ${CMAKE_CURRENT_BINARY_DIR}/${_testname}.moc)
qt4_generate_moc(${_testname}.cpp ${moc_output_file})
add_executable(${_testname}_exec ${_testSrcs} ${moc_output_file} )
___
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://www.cmake.org/mailman/listinfo/cmake
[CMake] Making it easier for downstreams to use my library
Hi, I've just tagged and tarballed a release candidate of Grantlee version 0.1.0. Grantlee is a Free Software string template system written in Qt and using CMake for its build system.[1] Most of my CMake knowledge is about writing simple CMakeLists.txt files to consume other libraries. Writing the necessary CMake files to so that downstreams can use my library is harder and I'm not sure I've done it right. I'd appreciate some review of the CMake stuff if anyone has the time and inclination. In particular, I'm not sure I'm doing the GrantleeUse.cmake file stuff correctly. I'm include()ing the Use file in my CMakeLists.txt file so that I can use its macros. Is that the usual way to do these things?[3] Also, the GrantleeConfig.cmake file looks wrong to me, but I don't know the right way to implement it. There's a lot of if(UNIX) etc for things which CMake must already know. I believe the solution I need there is importing and exporting the library, but I haven't figured out how to do it. [3] I'd like to know if any of this stuff should be a release blocker for me or will cause problems down the line, and get some information of what I'm doing wrong or what I could be doing better. Otherwise I'll probably make the 0.1.0 release as-is and fix the ugly-but-works stuff later. All the best, Steve. [1] http://www.grantlee.org [2] http://gitorious.org/grantlee/grantlee/blobs/master/cmake/modules/GrantleeUse.cmake [3] http://gitorious.org/grantlee/grantlee/blobs/master/cmake/modules/GrantleeConfig.cmake.in ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Making it easier for downstreams to use my library
Michael Wild wrote:
On 9. Apr, 2010, at 20:20 , Alexander Neundorf wrote:
[...]
which will create IMPORTED targets with the same names as in the
Grantlee project. So you can then set the variables
set(Grantlee_CORE_LIBRARIES grantlee_core ${QT_QTCORE_LIBRARIES})
set(Grantlee_GUI_LIBRARIES grantlee_gui ${QT_QTGUI_LIBRARIES})
I think this is not necessary at all when using the exported library
targets, all the dependencies should be there already.
Oops, yes, that's right, otherwise this feature wouldn't be so great after
all ;-)
Michael
Hi all,
Thanks for the tips and pointers. This is quite a big change and there's a
few things I'll need to try out, so I'm going to leave it as is for now and
fix this in a point release later.
All the best,
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Code and API review request for Qt5 CMake files
Michael Hertling wrote:
Suppose the Qt folks decide that Qt5's core module doesn't need to
be explicitly requested because it is prerequisite for everything
else.
Just to disseminate information here, this is already the case.
You can currently do this:
find_package(Qt5Declarative)
include_directories(${Qt5Declarative_INCLUDE_DIRS})
add_definitions(${Qt5Declarative_DEFINITONS})
target_link_libraries(foo ${Qt5Declarative_LIBRARIES})
Each find_package finds its dependencies and adds its dependencies values to
its own variables. So already, the core module (and in the above example,
the gui module) don't need to be explicitly mentioned.
This is one of the things I'd like feedback on, and on of the reasons I'm
asking people to try this out, or to read the generated Config files.
Can anyone say they've read the generated files? Has anyone confirm they
have run this or something like it? :
git clone git://gitorious.org/qt/qtbase.git
cd qtbase
./configure
ls lib/cmake
To see the input files for the generated config files see:
https://qt.gitorious.org/qt/qtbase/blobs/master/mkspecs/cmake/Qt5BasicConfig.cmake.in
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Code and API review request for Qt5 CMake files
Rolf Eike Beer wrote: Michael Hertling wrote: My main conclusion from the above-noted mess among CMake's current component-aware find modules is that we urgently need a convention how such modules and config files are intended to work. Hopefully, we can take a step forward; Qt5's advent is a good opportunity. Yes, please! And a good start would be cleaning up FindwxWidgets.cmake and porting it to use FPHSA so we get REQUIRED handling for free. Has this resulted in anything concrete being raised on the -developers list? 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Code and API review request for Qt5 CMake files
Michael Hertling wrote:
* Currently there is no Qt5Config.cmake.
Such a thing could probably exist and use the FIND_COMPONENTS to find
what was requested. [...]
Hi there,
Thank you for your insights on this issue. Do you have any other insights
into other issues I raised in the original post?
Absolutely, I would greatly appreciate a well-designed and component-
aware Qt5Config.cmake.
Yes. This thread confirms though that it is not a simple issue as I wrote
before :)
In general, there might be reasons why a multi-
component package's components that are to be used together should not
be requested in separate FIND_PACKAGE() invocations, see [1] and look
for package X with components A and B. However, I don't know if Qt5
will be the first example of that kind.
Your exact example is not covered by the Qt5 situation as far as I can tell.
However, similar issues already crop up (with Qt4 based systems). Can you
confirm whether you are aware of the issues around code like this regarding
the use of -DQT_GUI_LIB with the foo target so I know if I need to explain
it and whether we are on the same page? :
find_package(Qt4 REQUIRED Gui Test)
include(${QT_USE_FILE})
add_executable(bar ${QT_QTCORE_LIBRARIES} ${QT_QTGUI_LIBRARIES})
add_executable(foo ${QT_QTCORE_LIBRARIES} ${QT_QTTEST_LIBRARIES})
Referring to Qt5_XYZ_FOUND alone is not reliable because this variable
wouldn't have received a definite value if Qt5Config.cmake hasn't been
found by FIND_PACKAGE().
I don't actually see the problem with checking Qt5_XYZ_FOUND. Unset
variables are well defined as false in the if() command. Maybe I
misunderstand you?
I.e., the user would refer to this variable's
value before the FIND_PACKAGE() call; probably, that's not expected.
Why would the user refer to Qt5_Xml_FOUND before
find_package(Qt5 REQUIRED Xml)
?
[...] At least, I think
something like qt5_use_package is a better idea anyway.
First of all, I definitely agree to your criticism of UseQt4.cmake in
[5], and I appreciate your attempt to get rid of such a use file for
Qt5. However, I'd choose a Qt5Config.cmake over qt5_use_package(),
and my current vision for the former's usage is roughly, e.g.,
FIND_PACKAGE(Qt5 REQUIRED Xml)
SET_TARGET_PROPERTIES(t1 PROPERTIES
COMPILE_DEFINITIONS ${Qt5_DEFINITIONS}
Again, just to disseminate information, each Qt5moduleConfig.cmake file
sets Qt5module_DEFINITIONS for use with the add_definitions() command, and
Qt5module_COMPILE_DEFINITIONS for use with the COMPILE_DEFINITIONS
property. The difference is that one already contains the '-D' and the other
doesn't (and breaks if it is present).
So, in your example, that would be ${Qt5_COMPILE_DEFINITIONS} if a
Qt5Config.cmake exists some day.
INCLUDE_DIRECTORIES ${Qt5_INCLUDE_DIRS}) # If available one day.
The patches for this are in next but didn't get merged to master yet. It
should indeed be part of CMake 2.8.8 and function similar to what you write
here.
TARGET_LINK_LIBRARIES(t1 ${Qt5_LIBRARIES})
FIND_PACKAGE(Qt5 REQUIRED Sql)
SET_TARGET_PROPERTIES(t2 PROPERTIES
COMPILE_DEFINITIONS ${Qt5_DEFINITIONS}
INCLUDE_DIRECTORIES ${Qt5_INCLUDE_DIRS}) # If available one day.
TARGET_LINK_LIBRARIES(t2 ${Qt5_LIBRARIES})
with t2 not being overlinked due to accumulated results.
Yes, accumulation versus replacement for the values of all the variables set
by Qt5Config.cmake is also a complication that it introduces.
Some spontaneous questions/remarks on {cmake,qt5}_use_package():
- Do they need to be macros?
You mean as opposed to functions? I think they could be functions instead.
- What if _package is a multi-component one?
The macro as it is currently written (in a unit test in the Qt5 repo)
guardss the check for ${_package} with ${${_package}_FOUND}. My assumption
was that the convention was that if ${${_package}_FOUND} is true it doesn't
need to be found again, so in special cases where components need to be
specified, you would simply invoke find_package before the cmake_use_package
call:
cmake_use_package(t1 PNG)
find_package(Foo REQUIRED Xxx Yyy)
# Foo variables contain the requirements for Xxx and Yyy too.
cmake_use_package(t1 Foo) # Doesn't find Foo again, but uses the variables.
This thread indicates that that is not as conventional as I thought, but
this feature could be used to define what the convention should be as well
as create the incentive to create the convention.
- What about COMPILE_DEFINITIONS_CONFIG properties?
to be decided :) along with include directories for different configs (which
don't even have a syntax for representation in CMake yet, but it's not going
to be INCLUDE_DIRECTORIES_CONFIG) etc too.
- Target property INCLUDE_DIRECTORIES coming up in 2.8.8?
Yep.
- Using SET_PROPERTY(... APPEND_STRING ...) on COMPILE_FLAGS?
That doesn't account for duplicates.
- Do
list(APPEND _flags ...)
...
set_target_properties(... PROPERTIES
Re: [CMake] Setting COMPILE_FLAGS property on a target in only debug?
Andreas Mohr wrote: I'd like to add one more dimension to it: Thanks for the review. I'd think that Debug/Release isn't all that matters - what discussions all too conveniently leave out (possibly even the KDE Wiki-side target config discussion!) is platform-specific handling, too (Win32 / Win64 / cross-compiles / ...). After all, a full build declaration is x64/Release, not merely Release. But what is the CMAKE_BUILD_TYPE in this case? Also, how do you deal with these platform issues (Win32 / Win64 / cross-compiles / ...) currently? And for the sometimes desired per-configuration-type (**dynamic**) way of handling this CMake currently doesn't have much (if any) support. I'm not sure what this means. (Keep in mind that I have only ever used the UnixMakefiles and Ninja generators). Do you mean you want to run cmake once and then build multiple configurations (at the same time?)? Instead of what I do which would be mkdir debug cd debug cmake .. -DCMAKE_BUILD_TYPE=Debug make mkdir ../release cd ../release cmake .. -DCMAKE_BUILD_TYPE=Release make You want to build debug and release at the same time? 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Setting COMPILE_FLAGS property on a target in only debug?
Robert Dailey wrote: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615 This looks like an interesting discussion but seems like it would be a lot of work to complete. You're really targetting this for 2.8.9? It's likely to be partly complete by 2.8.9, but I don't know how much will still remain to do. The main reason to put the plan on the wiki page instead of just doing it as a lone ranger myself is to facilitate parallelization of the tasks. I haven't seen any input from Bill or David on this, I'd like to read what they have to say. The plan will probably have to be finished first. It's likely that we'll end up aiming for linking targets together (target_use_targets instead of target_use_package), and I think that part is actually achievable in 2.8.9. Slightly unrelated observation, but the target_use_package() description in the wiki linked to by your discussion thread doesn't make any sense to me. Also what do you mean by porcelain API? plumbing API is low-level API (eg calls to set_property) porcelain API is high-level API (eg calls to target_use_targets) 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Accepted way to add -fPIC onto CMAKE_CXX_FLAGS?
Michael Jackson wrote:
Linux really wants to have -fPIC for some of my code and I am trying to
detect linux and then add this flag for my project but I am having no
luck.
if (LINUX)
set(CMAKE_CXX_FLAGS ${CMAKE_CSS_FLAGS} -fPIC)
endif()
Is this NOT the way I should be doing this? It doesn't really fell
correct but nothing else (including this) seems to work.
Help?
In (upcoming) CMake 2.8.9 you can set the POSITION_INDEPENDENT_CODE property
on a target, or you can set the global variable
set(CMAKE_POSITION_INDEPENDENT_CODE ON)
to make all following targets position independent.
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://www.cmake.org/mailman/listinfo/cmake
[CMake] Should I create IMPORTED targets for executables?
Hi, For Qt 5 I'm creating IMPORTED targets for all the libraries, which has several benefits. I'm not sure if there are any benefits to creating IMPORTED targets for the executables too? Currently I just create variables with the full paths to the executables (moc, uic, rcc) instead. Is there any reason to change those to IMPORTED executables? 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Should I create IMPORTED targets for executables?
Stephen Kelly wrote: Hi, For Qt 5 I'm creating IMPORTED targets for all the libraries, which has several benefits. I'm not sure if there are any benefits to creating IMPORTED targets for the executables too? Currently I just create variables with the full paths to the executables (moc, uic, rcc) instead. Is there any reason to change those to IMPORTED executables? Hi, Just for informations sake, I've submitted a patch to create imported targets in the Qt 5 CMake files. https://codereview.qt-project.org/#change,31245 The justification is that it is future-proof in terms of future CMake features, and also in case we ever need to add properties with a target scope to executables. The alternative to that would otherwise be something like set(QT_UIC_EXECUTABLE_FOO Bar), which wouldn't have the same scope as the TARGET. I also don't want to end up with the situation we have with FindQt4.cmake where we need to define QT_USE_IMPORTED_TARGETS before finding the package because of backwards compatibility. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake files for static builds of Qt 5
Forwarding to the cmake list. Context: We're discussing the patch at: https://codereview.qt-project.org/#change,33193 in which a line similar to (eg from QtCore.prl): QMAKE_PRL_LIBS = -lpthread -lz -licui18n -licuuc -lm -ldl -pthread - lgthread-2.0 -lrt -lglib-2.0 The line in QtGui.prl looks like: QMAKE_PRL_LIBS = -L/usr/X11R6/lib64 -ljpeg -L/home/stephen/dev/src/qtbase- static/lib -lQtCore -lz -licui18n -licuuc -lm -ldl -pthread -lgthread-2.0 -lrt -lglib-2.0 -lpthread -lpng -lz -lGL is parsed out of files with an extension .prl which get shipped alongside the Qt libraries (and are created as part of a Qt build). That string is then used as the list of dependent libraries for the Qt targets for static builds. This is for convenience, so that users of Qt do not have to specify the static dependencies themselves, and so that I don't have to maintain the list 'artificially' in the cmake files in Qt either. However, there are issues, see below: On Tuesday, August 21, 2012 16:52:19 Stephen Kelly wrote: On Tuesday, August 21, 2012 08:21:01 Clinton Stimpson wrote: On Tuesday, August 21, 2012 01:32:33 PM Stephen Kelly wrote: This means adding a string of -L and -l entries to the LINK_INTERFACE_LIBRARIES, which isn't particularly nice, but I don't think it has a downside, unless you see one? Doesn't that add -L and -l entries for the Qt libraries themselves as well? Yes, it does. For example, QtGui depends on QtCore, and is there a -lQtCore in QtGui's prl file. Yes. I'm not really aware of what kinds of problems that causes though. This kind of thing prevents being able to create cmake export files and have them work on other Linux machines which may have a different location these system libraries. Yes, I suppose this set-up assumes that the static Qt and the user of it are built with the same environment. Maybe we already had that problem, but with the old way, we could fix the Find* files in CMake. With this way, we can't fix the prl files. Yes, although prl files are also just text files. Arguably if someone is moving a Qt installation to another machine or environment (I'm not sure that's supposed to work anyway) maybe they should change those prl files too. Moving to a different machine/environment means that those libraries could have been built with different flags/be different versions etc. Building third party software against this 'moved' Qt might then be using a different static library than the Qt itself. Would you really expect that to work all the time? It sounds hacky to even attempt. It feels like going against the grain of CMake's way of handling libraries. Yes, but it is the maintainable solution unfortunately. So, for the cmake list - Is moving a static library (Qt in this case) to an evironment different from the build environment expected to work? If QtCore is built statically against icuuc version 46 and then moved to an environment where icu version 48 is available, but not 46, and you build your software linked with the static Qt and the other version of icu, do you expect it to work? Consdier the query repeated with any library dependency you like. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake files for static builds of Qt 5
Clinton Stimpson wrote: To clarify, I wasn't talking about moving Qt. I was talking about a pre- compiled libraries that depend on Qt being put on another machine, along with their cmake export files. Thanks for clarifying! The QMAKE_PRL_LIBS has paths -L/usr/X11R6/lib64 -L/home/stephen/dev/src/qtbase-static/lib And I'm concerned those paths would show up in the export file. Yes, I see what you mean. After a quick test, CMake exports files generally don't seem to duplicate the information in dependent imported targets. If that's the case, then there doesn't seem to be any problem (apart from the duplication issue - though I think CMake itself might handle that properly alreday). The contents of the QtFoo.prl file will not be duplicated and must contain correct information anyway, as otherwise the Qt installation would be broken. Also, to clarify a bit, a path to my source directory appears above as it is from a prl file in my build directory. At install time the prl files are re- generated with install-prefix paths. Also, I dislike adding -L/home/stephen/dev/src/qtbase-static/lib -lQtCore when we already have /home/stephen/dev/src/qtbase-static/lib/libQtCore.so when using QtGui. To clarify here too, we're talking only about static libraries, not .so files. Thanks, Steve. -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [Development] CMake for Qt5: Cross Compilation for Windows using MinGW-w64
On Thursday, August 30, 2012 23:53:27 Loaden wrote: Hi, there! I am try to cross compilation qt5 apps on Linux. By this wiki point: http://www.cmake.org/Wiki/CmakeMingw I can make the simple qt5 demo works. This issue is solved. I forgot reply-to-all. http://lists.qt-project.org/pipermail/development/2012-August/005998.html Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.10-rc1 ready for testing!
Robert Dailey wrote: Could we get a list of all the new generator expressions? Is there 2.8.10 documentation online somewhere that might have them documented? I don't think there's generated html docs, but here's the new addition to the INCLUDE_DIRECTORIES target property documentation: Contents of INCLUDE_DIRECTORIES may use generator expressions with the syntax $ Generator expressions are evaluted during build system generation to produce information specific to each build configuration. Valid expressions are: $0:... = empty string (ignores ...) $1:... = content of ... $CONFIG:cfg = '1' if config is cfg, else '0' $CONFIGURATION = configuration name $BOOL:... = '1' if the '...' is true, else '0' $STREQUAL:a,b = '1' if a is STREQUAL b, else '0' $ANGLE-R= A literal ''. Used to compare strings which contain a '' for example. $COMMA = A literal ','. Used to compare strings which contain a ',' for example. $TARGET_FILE:tgt= main file (.exe, .so.1.2, .a) $TARGET_LINKER_FILE:tgt = file used to link (.a, .lib, .so) $TARGET_SONAME_FILE:tgt = file with soname (.so.3) where tgt is the name of a target. Target file expressions produce a full path, but _DIR and _NAME versions can produce the directory and file name components: $TARGET_FILE_DIR:tgt/$TARGET_FILE_NAME:tgt $TARGET_LINKER_FILE_DIR:tgt/$TARGET_LINKER_FILE_NAME:tgt $TARGET_SONAME_FILE_DIR:tgt/$TARGET_SONAME_FILE_NAME:tgt $TARGET_PROPERTY:tgt,prop = The value of the property prop on the target tgt. Note that tgt is not added as a dependency of the target this expression is evaluated on. Boolean expressions: $AND:?[,?]... = '1' if all '?' are '1', else '0' $OR:?[,?]...= '0' if all '?' are '0', else '1' $NOT:? = '0' if '?' is '1', else '1' where '?' is always either '0' or '1'. Expressions with an implicit 'this' target: $TARGET_PROPERTY:prop = The value of the property prop on the target on which the generator expression is evaluated. * 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.10-rc1 ready for testing!
Robert Dailey wrote: Could we get a list of all the new generator expressions? Is there 2.8.10 documentation online somewhere that might have them documented? I don't think there's generated html docs, but here's the new addition to the INCLUDE_DIRECTORIES target property documentation: Contents of INCLUDE_DIRECTORIES may use generator expressions with the syntax $ Generator expressions are evaluted during build system generation to produce information specific to each build configuration. Valid expressions are: $0:... = empty string (ignores ...) $1:... = content of ... $CONFIG:cfg = '1' if config is cfg, else '0' $CONFIGURATION = configuration name $BOOL:... = '1' if the '...' is true, else '0' $STREQUAL:a,b = '1' if a is STREQUAL b, else '0' $ANGLE-R= A literal ''. Used to compare strings which contain a '' for example. $COMMA = A literal ','. Used to compare strings which contain a ',' for example. $TARGET_FILE:tgt= main file (.exe, .so.1.2, .a) $TARGET_LINKER_FILE:tgt = file used to link (.a, .lib, .so) $TARGET_SONAME_FILE:tgt = file with soname (.so.3) where tgt is the name of a target. Target file expressions produce a full path, but _DIR and _NAME versions can produce the directory and file name components: $TARGET_FILE_DIR:tgt/$TARGET_FILE_NAME:tgt $TARGET_LINKER_FILE_DIR:tgt/$TARGET_LINKER_FILE_NAME:tgt $TARGET_SONAME_FILE_DIR:tgt/$TARGET_SONAME_FILE_NAME:tgt $TARGET_PROPERTY:tgt,prop = The value of the property prop on the target tgt. Note that tgt is not added as a dependency of the target this expression is evaluated on. Boolean expressions: $AND:?[,?]... = '1' if all '?' are '1', else '0' $OR:?[,?]...= '0' if all '?' are '0', else '1' $NOT:? = '0' if '?' is '1', else '1' where '?' is always either '0' or '1'. Expressions with an implicit 'this' target: $TARGET_PROPERTY:prop = The value of the property prop on the target on which the generator expression is evaluated. * 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.10-rc1 ready for testing!
Rolf Eike Beer wrote:
$TARGET_PROPERTY:prop = The value of the property prop on
the target on which the generator expression is evaluated.
Then tell me on which target an include_directories is evaluated on ;)
Each of them:
add_executable(foo ${foo_SRCS})
add_library(bar ${bar_SRCS})
include_directories(
$$STREQUAL:$TARGET_PROPERTY:TYPE,EXECUTABLE:/some/include
)
add_executable(bat ${bat_SRCS})
add_library(bag ${bag_SRCS})
The expression will be evaluated for each target, the TYPE will be checked,
and the include directory added or not.
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] GenerateExportHeader for module library
Gregoire Aujay wrote: Hello, I want to create a module with two symbols exported with visual: startPlugin stopPlugin I wish I could use the convenient GENERATE_EXPORT_HEADER function to do so. Is there any reason why the GENERATE_EXPORT_HEADER function is disabled for the MODULE library type ? When I wrote GenerateExportHeader, I didn't know of any reason to link to a MODULE. I thought MODULEs were always plugins to be loaded at runtime? What does 'two symbols exported with visual' mean? 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problems with CMake and static Qt plugins
dcrespol wrote: Hi, norulez. With @Thiago: QT_STATICPLUGIN does the trick , what do you mean? How and where did you use this? If possible, can you please include both your final plugin and application CMakeLists.txt files? It was probably a response to Thiago on the Qt mailing list. Use add_definitions(-DQT_STATICPLUGIN) when building your plugin or set_property(TARGET theplugin APPEND PROPERTY COMPILE_DEFINITIONS QT_STATICPLUGIN ) 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Should automoc automatically add CMAKE_CURRENT_BINARY_DIR to the include_directories?
David Doria wrote:
When using automoc, I still have to do:
include_directories(${CMAKE_CURRENT_BINARY_DIR})
so that the compiler can find the MOCed files that get created in the
build directory. Should this be done automatically so there is one
less thing the user has to worry about?
That was discussed here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/1367/focus=1813
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://www.cmake.org/mailman/listinfo/cmake
[CMake] Testing Qt 5 Beta 2 CMake files
Hi there, I emailed before about reviewing Config files that are being shipped with Qt 5 and got great feedback: http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/7165/focus=41551 Now that Qt 5 beta 2 is out, I'd like to ask for feedback again on anything that can still be changed before Qt 5.0. Note that Qt 5 beta 1 was broken regarding cmake files on Windows and Mac. As those are not primary platforms for me, I'd particularly appreciate feedback on those. You can download Qt 5 beta 2 here: http://qt-project.org/downloads Known issues are here: http://qt-project.org/wiki/Qt500beta2KnownIssues cmake related documentation is here: http://doc-snapshot.qt-project.org/5.0/qtdoc/cmake-manual.html unit tests are here: https://qt.gitorious.org/qt/qtbase/trees/master/tests/auto/cmake Thanks for any feedback! 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://www.cmake.org/mailman/listinfo/cmake
[CMake] ActiveQt with CMake?
Hi there, I'm attempting to write a unit test for the Qt 5 ActiveQt module: https://codereview.qt-project.org/#change,41554 The problem is that I don't have any prior experience with ActiveQt, and in particular ActiveQt with CMake. It seems that as part of the build, qmake is invoking the built executable with the -dumpidl command line option. Is a post-build step or a cpack macro or so needed for that kind of stuff? Has anyone using CMake with ActiveQt come up against that issue before? How did you solve it? 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ActiveQt with CMake?
Pau Garcia i Quiles wrote: On Tue, Dec 4, 2012 at 11:28 AM, Stephen Kelly steve...@gmail.com wrote: Hi there, I'm attempting to write a unit test for the Qt 5 ActiveQt module: https://codereview.qt-project.org/#change,41554 The problem is that I don't have any prior experience with ActiveQt, and in particular ActiveQt with CMake. It seems that as part of the build, qmake is invoking the built executable with the -dumpidl command line option. Is a post-build step or a cpack macro or so needed for that kind of stuff? Has anyone using CMake with ActiveQt come up against that issue before? How did you solve it? Take a look at this mail from 8 years ago, it explains all the steps and the rationale and usefulness of each of them: http://lists.trolltech.com/qt-interest/2004-05/thread00936-0.html Yes, I found that in my search. It's linked in the commit message of the Qt review request I linked to. I think a few new macros (CMake, not CPack) are needed to generate the IDL, then compile it to the type library (.tlb), then combine it with the executable. Amb maybe even one that combines those three in one, which will be what people usually do. What surprises me is that in the time since ActiveQt and CMake could be used together, no one else has written such macros. Or has everyone using the ActiveQt modules written such macros separately? Or is it more likely that people using ActiveQt have manually done the post- build steps, such as -dumpidl and creating the IDL type libbrary, outside of CMake? I'm trying to find out how people use ActiveQt/CMake in practice in the real world, what compatibility needs to be kept, and if the CMake files generated for Qt 5 are useful at all, or need to be extended before becoming useful. Your reply makes me think that the Qt5 patch is useful to the same extent as the FindQt4 patch was useful - that it is enough that people can do the rest themselves (outside of CMake if needed)? Can you confirm? 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ActiveQt with CMake?
Pau Garcia i Quiles wrote: I would say most people are not using ActiveQt and CMake together, plain and simple. For the very few who do, they are probably only using the Qt application as a client (i. e. load an ActiveX component), not to write servers. Aha, and the implication is that in that case, the post-build steps such as running with -dumpidl and creating the IDL type library are not necessary. Is that correct? How does one do that? By using the QAxContainer module and not using QAxServer? Are there any other post-build steps in that case at all? Are those macros needed and useful? Very much so . Adding them to FindQt4 would certainly make sense to me, too. I'm sure if they get written they'll be sufficiently generic to target both Qt versions without too much modification. However, if no one uses ActiveQt with CMake, do we need to do that at all? 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ActiveQt with CMake?
Pau Garcia i Quiles wrote: On Wed, Dec 5, 2012 at 5:00 PM, Stephen Kelly steve...@gmail.com wrote: Pau Garcia i Quiles wrote: I would say most people are not using ActiveQt and CMake together, plain and simple. For the very few who do, they are probably only using the Qt application as a client (i. e. load an ActiveX component), not to write servers. Aha, and the implication is that in that case, the post-build steps such as running with -dumpidl and creating the IDL type library are not necessary. Is that correct? How does one do that? By using the QAxContainer module and not using QAxServer? Are there any other post-build steps in that case at all? Yes, that's right. When you want to use an ActiveX component (e. g. Adobe Reader), you embed it using a QAxContainer. When you want to create an application that will be embeddable by other applications, you create a QAxServer. Your application/library could use an ActiveX component and be itself an ActiveX component to be embedded for others (simple case: you create an ActiveX component which is an enhanced reader that extends Adobe Reader), but it's not really common. Even less common using Qt (you would typically use C++ or C# for this kind of task). And even less common if it's Qt using CMake, for starters because being Windows-only, it makes little sense (other than moving from one version of Visual C++ to another) to use CMake for that project instead of plain Visual C++ project. All that lumped together explains why we have never seen this. Thanks for all that information. Are those macros needed and useful? Very much so . Adding them to FindQt4 would certainly make sense to me, too. I'm sure if they get written they'll be sufficiently generic to target both Qt versions without too much modification. However, if no one uses ActiveQt with CMake, do we need to do that at all? I think those macros are not really hard to write and if those macros are not available, we can be sure no one will use ActiveQt with CMake for the next 8 years either :-) Well, at least it seems to make sense to commit the Qt5ActiveQt patch even without the macros as they can be added later. I don't think I have the base knowledge (or inclination) to implement them myself. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Testing Qt 5 RC 1 CMake files
John Drescher wrote: I emailed before about reviewing Config files that are being shipped with Qt 5 and got great feedback: http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/7165/focus=41551 Now that Qt 5 beta 2 is out, I'd like to ask for feedback again on anything that can still be changed before Qt 5.0. Note that Qt 5 beta 1 was broken regarding cmake files on Windows and Mac. As those are not primary platforms for me, I'd particularly appreciate feedback on those. You can download Qt 5 beta 2 here: http://qt-project.org/downloads Known issues are here: http://qt-project.org/wiki/Qt500beta2KnownIssues cmake related documentation is here: http://doc-snapshot.qt-project.org/5.0/qtdoc/cmake-manual.html unit tests are here: https://qt.gitorious.org/qt/qtbase/trees/master/tests/auto/cmake Thanks for any feedback! I will try to take a look at this on a windows 7 x64 test box when I can. Thanks for the offer. Did anything come of this? Note that an RC1 was released in the mean-time: http://qt-project.org/downloads That does not change anything with regard to the CMake files however. Another RC will be released in the coming days, and within about 2 weeks we'll have the 5.0 final. Feedback is mostly welcomed before that. Feedback on that release will be welcomed too of course, but if anything needs changing, the release is already out so people will be already affected :). 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Testing Qt 5 RC 1 CMake files
John Drescher wrote: I had some trouble building a x64 version of Qt 5.0 beta2 but then after getting past that I found out that vtk-5.10.X would not work with Qt5 so it pretty much ended what I wanted to test since pretty much all of my current code uses vtk. I see. I just tried building VTK master in my Qt 4 environment, and I can't figure out how to build the Qt parts of it. I'm sure it's easy to port to Qt 5, but if I can't figure out how to build the Qt parts at all, then I can't do that. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Testing Qt 5 RC 1 CMake files
Clinton Stimpson wrote:
I took a peek at building it earlier with Qt5.
Great, thanks for that.
I started making changes and one of the more surprising ones was that
#include QtGui/QWidget
pulled in my Qt4 QWidget from /usr/include/QtGui/QWidget.
Instead of Qt5's QtWidgets/QWidget. That led to confusing linker errors.
Another reason never to use 'module includes' :). I always discourage their
use.
I got as far as trying to build some examples, but many of the examples
seem
to be broken. Does anyone know if the master branch has become stable and
whether functionality and examples have been restored since the start of
the breaking modularization changes months ago?
I stopped when I saw these kinds of build problems.
I didn't try running any examples, but I also ported it to Qt 5. My patch
for that is attached. John, the patch for older VTK versions should be
similar if you wish to try it.
Thanks,
Steve.
From 5dfdb36e378ed81967faae18c0d5ef60bbfde426 Mon Sep 17 00:00:00 2001
From: Stephen Kelly stephen.ke...@kdab.com
Date: Wed, 12 Dec 2012 17:42:53 +0100
Subject: [PATCH] Build with Qt 4 and 5.
---
CMake/ECMQt4To5Porting.cmake| 98 +++
CMake/FindQt5Transitional.cmake | 77 +
Examples/GUI/Qt/GraphicsView/CMakeLists.txt |2 +-
GUISupport/Qt/CMakeLists.txt|3 +-
GUISupport/Qt/Q4VTKWidgetPlugin.cxx |3 +-
GUISupport/Qt/Q4VTKWidgetPlugin.h |5 ++
GUISupport/Qt/QVTKWidget.cxx|2 +-
GUISupport/Qt/QVTKWidget.h |2 +-
GUISupport/Qt/Testing/Cxx/CMakeLists.txt|3 +-
GUISupport/QtOpenGL/CMakeLists.txt |3 +-
GUISupport/QtOpenGL/QVTKGraphicsItem.h |2 +-
GUISupport/QtSQL/CMakeLists.txt |3 +-
GUISupport/QtWebkit/CMakeLists.txt |3 +-
GUISupport/QtWebkit/vtkQtRichTextView.cxx |2 -
Rendering/Qt/CMakeLists.txt |3 +-
Views/Qt/CMakeLists.txt |3 +-
Views/Qt/vtkQtView.cxx |3 +-
17 files changed, 195 insertions(+), 22 deletions(-)
create mode 100644 CMake/ECMQt4To5Porting.cmake
create mode 100644 CMake/FindQt5Transitional.cmake
diff --git a/CMake/ECMQt4To5Porting.cmake b/CMake/ECMQt4To5Porting.cmake
new file mode 100644
index 000..9fc84a6
--- /dev/null
+++ b/CMake/ECMQt4To5Porting.cmake
@@ -0,0 +1,98 @@
+
+set(QT_QTGUI_LIBRARIES
+ ${Qt5Gui_LIBRARIES}
+ ${Qt5Widgets_LIBRARIES}
+ ${Qt5PrintSupport_LIBRARIES}
+ ${Qt5Svg_LIBRARIES}
+)
+
+set(QT_INCLUDES
+${Qt5Gui_INCLUDE_DIRS}
+${Qt5Widgets_INCLUDE_DIRS}
+${Qt5PrintSupport_INCLUDE_DIRS}
+${Qt5Svg_INCLUDE_DIRS}
+)
+set(QT_QTGUI_LIBRARY ${QT_QTGUI_LIBRARIES})
+
+set(_qt_modules
+ Core
+ Declarative
+ Widgets
+ Script
+ ScriptTools
+ DBus
+ Network
+ Test
+ Designer
+ Concurrent
+ Xml
+ UiTools
+ Qml
+ Quick1
+ WebKit
+ WebKitWidgets
+ Sql
+ OpenGL
+)
+
+foreach(_module ${_qt_modules})
+string(TOUPPER ${_module} _module_upper)
+set(QT_QT${_module_upper}_LIBRARIES ${Qt5${_module}_LIBRARIES})
+set(QT_QT${_module_upper}_LIBRARY ${QT_QT${_module_upper}_LIBRARIES})
+list(APPEND QT_INCLUDES ${Qt5${_module}_INCLUDE_DIRS})
+set(QT_QT${_module_upper}_FOUND ${Qt5${_module}_FOUND})
+endforeach()
+
+list(APPEND QT_QTCORE_LIBRARIES ${Qt5Concurrent_LIBRARIES})
+list(APPEND QT_QTCORE_LIBRARY ${Qt5Concurrent_LIBRARIES})
+
+set(QT_QTDECLARATIVE_LIBRARIES ${Qt5Quick1_LIBRARIES})
+set(QT_QTDECLARATIVE_LIBRARY ${Qt5Quick1_LIBRARIES})
+
+get_target_property(QT_QMAKE_EXECUTABLE Qt5::qmake LOCATION)
+get_target_property(QT_RCC_EXECUTABLE Qt5::rcc LOCATION)
+if (TARGET Qt5::uic)
+get_target_property(QT_UIC_EXECUTABLE Qt5::uic LOCATION)
+endif()
+
+if (TARGET Qt5::qdbuscpp2xml)
+get_target_property(QT_QDBUSCPP2XML_EXECUTABLE Qt5::qdbuscpp2xml LOCATION)
+endif()
+
+if (TARGET Qt5::qdbusxml2cpp)
+get_target_property(QT_QDBUSXML2CPP_EXECUTABLE Qt5::qdbusxml2cpp LOCATION)
+endif()
+
+add_definitions(-DQT_DISABLE_DEPRECATED_BEFORE=0)
+
+macro(qt4_wrap_ui)
+ qt5_wrap_ui(${ARGN})
+endmacro()
+
+macro(qt4_wrap_cpp)
+ qt5_wrap_cpp(${ARGN})
+endmacro()
+
+macro(qt4_generate_moc)
+ qt5_generate_moc(${ARGN})
+endmacro()
+
+macro(qt4_add_dbus_adaptor)
+ qt5_add_dbus_adaptor(${ARGN})
+endmacro()
+
+macro(qt4_add_dbus_interfaces)
+ qt5_add_dbus_interfaces(${ARGN})
+endmacro()
+
+macro(qt4_add_dbus_interface)
+ qt5_add_dbus_interface(${ARGN})
+endmacro()
+
+macro(qt4_generate_dbus_interface)
+ qt5_generate_dbus_interface(${ARGN})
+endmacro()
+
+macro(qt4_add_resources)
+ qt5_add_resources(${ARGN})
+endmacro()
diff --git a/CMake/FindQt5Transitional.cmake b/CMake/FindQt5Transitional.cmake
new file mode 100644
index 000..452c0f7
--- /dev/null
+++ b/CMake/FindQt5Transitional.cmake
@@ -0,0 +1,77 @@
+
+find_package(Qt5Core QUIET)
+
+if (Qt5Core_FOUND)
+ if (NOT Qt5Transitional_FIND_COMPONENTS)
+foreach
Re: [CMake] Testing Qt 5 RC 1 CMake files
David Cole wrote:
Doesn't seem like return false; is quite the right implementation
for vtkQtView::SaveImage...
;-)
I can't get anything past you :). Though in my defense the commit message
only says it builds :).
I found another issue with a QtNetwork include, so an updated version is
attached.
Thanks,
Steve.
From e825f9f4da012bdf4e129aeb238b808c0e714fc4 Mon Sep 17 00:00:00 2001
From: Stephen Kelly stephen.ke...@kdab.com
Date: Wed, 12 Dec 2012 17:42:53 +0100
Subject: [PATCH] Build with Qt 4 and 5.
---
CMake/ECMQt4To5Porting.cmake| 98 +++
CMake/FindQt5Transitional.cmake | 77 +
Examples/GUI/Qt/GraphicsView/CMakeLists.txt |2 +-
GUISupport/Qt/CMakeLists.txt|3 +-
GUISupport/Qt/Q4VTKWidgetPlugin.cxx |3 +-
GUISupport/Qt/Q4VTKWidgetPlugin.h |5 ++
GUISupport/Qt/QVTKWidget.cxx|2 +-
GUISupport/Qt/QVTKWidget.h |2 +-
GUISupport/Qt/Testing/Cxx/CMakeLists.txt|3 +-
GUISupport/QtOpenGL/CMakeLists.txt |3 +-
GUISupport/QtOpenGL/QVTKGraphicsItem.h |2 +-
GUISupport/QtSQL/CMakeLists.txt |3 +-
GUISupport/QtWebkit/CMakeLists.txt |3 +-
GUISupport/QtWebkit/vtkQtRichTextView.cxx |2 -
Rendering/Qt/CMakeLists.txt |3 +-
Views/Qt/CMakeLists.txt |3 +-
Views/Qt/vtkQtView.cxx |7 +-
17 files changed, 199 insertions(+), 22 deletions(-)
create mode 100644 CMake/ECMQt4To5Porting.cmake
create mode 100644 CMake/FindQt5Transitional.cmake
diff --git a/CMake/ECMQt4To5Porting.cmake b/CMake/ECMQt4To5Porting.cmake
new file mode 100644
index 000..9fc84a6
--- /dev/null
+++ b/CMake/ECMQt4To5Porting.cmake
@@ -0,0 +1,98 @@
+
+set(QT_QTGUI_LIBRARIES
+ ${Qt5Gui_LIBRARIES}
+ ${Qt5Widgets_LIBRARIES}
+ ${Qt5PrintSupport_LIBRARIES}
+ ${Qt5Svg_LIBRARIES}
+)
+
+set(QT_INCLUDES
+${Qt5Gui_INCLUDE_DIRS}
+${Qt5Widgets_INCLUDE_DIRS}
+${Qt5PrintSupport_INCLUDE_DIRS}
+${Qt5Svg_INCLUDE_DIRS}
+)
+set(QT_QTGUI_LIBRARY ${QT_QTGUI_LIBRARIES})
+
+set(_qt_modules
+ Core
+ Declarative
+ Widgets
+ Script
+ ScriptTools
+ DBus
+ Network
+ Test
+ Designer
+ Concurrent
+ Xml
+ UiTools
+ Qml
+ Quick1
+ WebKit
+ WebKitWidgets
+ Sql
+ OpenGL
+)
+
+foreach(_module ${_qt_modules})
+string(TOUPPER ${_module} _module_upper)
+set(QT_QT${_module_upper}_LIBRARIES ${Qt5${_module}_LIBRARIES})
+set(QT_QT${_module_upper}_LIBRARY ${QT_QT${_module_upper}_LIBRARIES})
+list(APPEND QT_INCLUDES ${Qt5${_module}_INCLUDE_DIRS})
+set(QT_QT${_module_upper}_FOUND ${Qt5${_module}_FOUND})
+endforeach()
+
+list(APPEND QT_QTCORE_LIBRARIES ${Qt5Concurrent_LIBRARIES})
+list(APPEND QT_QTCORE_LIBRARY ${Qt5Concurrent_LIBRARIES})
+
+set(QT_QTDECLARATIVE_LIBRARIES ${Qt5Quick1_LIBRARIES})
+set(QT_QTDECLARATIVE_LIBRARY ${Qt5Quick1_LIBRARIES})
+
+get_target_property(QT_QMAKE_EXECUTABLE Qt5::qmake LOCATION)
+get_target_property(QT_RCC_EXECUTABLE Qt5::rcc LOCATION)
+if (TARGET Qt5::uic)
+get_target_property(QT_UIC_EXECUTABLE Qt5::uic LOCATION)
+endif()
+
+if (TARGET Qt5::qdbuscpp2xml)
+get_target_property(QT_QDBUSCPP2XML_EXECUTABLE Qt5::qdbuscpp2xml LOCATION)
+endif()
+
+if (TARGET Qt5::qdbusxml2cpp)
+get_target_property(QT_QDBUSXML2CPP_EXECUTABLE Qt5::qdbusxml2cpp LOCATION)
+endif()
+
+add_definitions(-DQT_DISABLE_DEPRECATED_BEFORE=0)
+
+macro(qt4_wrap_ui)
+ qt5_wrap_ui(${ARGN})
+endmacro()
+
+macro(qt4_wrap_cpp)
+ qt5_wrap_cpp(${ARGN})
+endmacro()
+
+macro(qt4_generate_moc)
+ qt5_generate_moc(${ARGN})
+endmacro()
+
+macro(qt4_add_dbus_adaptor)
+ qt5_add_dbus_adaptor(${ARGN})
+endmacro()
+
+macro(qt4_add_dbus_interfaces)
+ qt5_add_dbus_interfaces(${ARGN})
+endmacro()
+
+macro(qt4_add_dbus_interface)
+ qt5_add_dbus_interface(${ARGN})
+endmacro()
+
+macro(qt4_generate_dbus_interface)
+ qt5_generate_dbus_interface(${ARGN})
+endmacro()
+
+macro(qt4_add_resources)
+ qt5_add_resources(${ARGN})
+endmacro()
diff --git a/CMake/FindQt5Transitional.cmake b/CMake/FindQt5Transitional.cmake
new file mode 100644
index 000..452c0f7
--- /dev/null
+++ b/CMake/FindQt5Transitional.cmake
@@ -0,0 +1,77 @@
+
+find_package(Qt5Core QUIET)
+
+if (Qt5Core_FOUND)
+ if (NOT Qt5Transitional_FIND_COMPONENTS)
+foreach(_component
+ Core
+ Gui
+ DBus
+ Designer
+ Declarative
+ Script
+ ScriptTools
+ Network
+ Test
+ Xml
+ Svg
+ Sql
+ Widgets
+ PrintSupport
+ Concurrent
+ UiTools
+ WebKit
+ WebKitWidgets
+ OpenGL
+)
+ find_package(Qt5${_component})
+ list(APPEND QT_LIBRARIES ${Qt5${_component}_LIBRARIES})
+endforeach()
+ else()
+foreach(_component ${Qt5Transitional_FIND_COMPONENTS})
+ find_package(Qt5${_component} REQUIRED
Re: [CMake] Testing Qt 5 RC 1 CMake files
Stephen Kelly wrote: Note that an RC1 was released in the mean-time: http://qt-project.org/downloads That does not change anything with regard to the CMake files however. Qt 5.0 final has now been released :). http://blog.qt.digia.com/blog/2012/12/19/qt-5-0/ It also does not change anything regarding the CMake files. Enjoy, and do let me know if anything doesn't work on the CMake side (and also if it does work). Useful links: http://doc-snapshot.qt-project.org/5.0/qtdoc/cmake-manual.html http://www.kdab.com/using-cmake-with-qt-5/ http://quickgit.kde.org/index.php?p=extra-cmake-modules.gita=blobf=find- modules%2FFindQt5Transitional.cmake 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What is the proper cross-platform way to link the Python library?
Alan W. Irwin wrote: If/when that python.org bug is fixed I will look into the Is it reported? If not it won't get fixed. I assume you saw this? http://thread.gmane.org/gmane.comp.science.paraview.user/10956/focus=11019 I wonder if that David reported it either. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Ninja and *.i targets
Bill Hoffman wrote: On 1/5/2013 3:49 PM, Óscar Fuentes wrote: With the `Unix Makefiles' generator, a foo.i target is generated for foo.cpp. That's very convenient. However, ninja doesn't list such targets under `ninja help' and `ninja foo.i' complains about unknown target. Is this feature missing from the ninja generator? Is it because is hard to implement or just lack of time? I'm using cmake 2.8.9 and ninja 1.0.0 on Linux. This is a missing feature. Can you create a feature request for it in the bug tracker? While at it, you comb this thread to see if there are other feature requests there which are not in the bug tracker: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3471/focus=3475 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Ninja and *.i targets
Óscar Fuentes wrote: Stephen Kelly steve...@gmail.com writes: While at it, you comb this thread to see if there are other feature requests there which are not in the bug tracker: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3471/focus=3475 Good idea. Apart from the .i targets, the only non-controversial unimplemented feature I see is the generation of .s targets. Created a feature request here: http://public.kitware.com/Bug/view.php?id=13839 Great, thanks! -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] LINK_PRIVATE and install(EXPORT behavior
Gregoire Aujay wrote: Hello, I am using cmake 2.8.10.2 on windows. I want a library A to link to a 3rdParty library B. I thought that using LINK_PRIVATE version of the target_link_libraries function should avoid B to be in the link interface of A. But if I export A, B's full path is in IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG. I know that if I declare B as an imported library I will not have B's full path in IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG but only B which might be ok. But still I think that the PRIVATE_LINK should totally remove B from A's link interface. Is this the correct behavior? It works for me. Please provide a testcase. 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://www.cmake.org/mailman/listinfo/cmake
[CMake] How to handle RelWithDebInfo and MinSizeRel when not built?
Hi, In Qt 5, we create CMake Config files and ship them with the Qt installation to make it possible to use Qt 5 with CMake. Qt on Windows and Mac is packaged with both a debug configuration and a release configuration, so an IMPORTED library is created with both a DEBUG location and a RELEASE location. We don't currently create a location for RelWithDebInfo or MinSizeRel, leading to this bug report: https://bugreports.qt-project.org/browse/QTBUG-29186 I checked the FindQt4 module, and it also does not create IMPORTED locations for RelWithDebInfo or MinSizeRel either, so I wonder if this issue has come up before? As I don't use Windows or Mac, I'm not really familiar with those systems or configurations, so I'm looking for some guidance on what should be done here. The suggestion in the bug report looks somewhat reasonable to me, but then again, we don't actually create separate debug info, and the 'Release' configuration would be no different to the 'RelWithDebInfo' configuration, so it's sort of a 'lie'. The real need for it though is probably that it allows the downstream of Qt to use RelWithDebInfo themselves? The alternative way to do that would be to set the MAP_IMPORTED_CONFIG* properties. I'm not sure whether I should advise that and close the bug report, or should I implement the suggested change. Any ideas? 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using Qt5 with cmake
Bogdan Cristea wrote: Le vendredi 18 janvier 2013 à 15:22 +, Laszlo Papp a écrit : What is wrong about Stephen's post? It has been working for me in several projects. A line like this find_package(Qt5Declarative) generates a warning about missing FindQt5Declarative.cmake which is not provided by Qt5 nor cmake. Maybe I am missing something, but I am not able to use Qt5 with cmake following that post. Hi, I'm afraid the post is a little but outdated. Qt5Declarative was renamed to QtQuick1 before the Qt 5 release, so try to find that instead. I'll see about updating the blog post. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to handle RelWithDebInfo and MinSizeRel when not built?
John Drescher wrote: The suggestion in the bug report looks somewhat reasonable to me, but then again, we don't actually create separate debug info, and the 'Release' configuration would be no different to the 'RelWithDebInfo' configuration, so it's sort of a 'lie'. The real need for it though is probably that it allows the downstream of Qt to use RelWithDebInfo themselves? The alternative way to do that would be to set the MAP_IMPORTED_CONFIG* properties. I'm not sure whether I should advise that and close the bug report, or should I implement the suggested change. Any ideas? As a windows programmer who regularly uses CMake generated RelWithDebInfo targets with Qt4 since 2008 I believe the behavior of using the Release versions for RelWithDebugInfo is fine (and actually preferred for me). Hi John, Thanks for your input. Do you have to do anything in particular to enable this when working with FindQt4.cmake? If I need to debug deeply into a Qt problem I will switch to use the Debug build however most of the time for itk or vtk I want to use RelWithDebInfo to debug since these tend to be slow to Debug in Debug mode that is when I use dicom images that are similar resolution to what my programs typically use. Do you have to do anything in particular to enable this when working with FindQt4.cmake? Or do you mean that you use vtk in RelWithDebInfo config, and Qt in Release config in that case? 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QT4 Module Patch Request
Nicolas Tisserand wrote:
Hi,
snip
Hope that helps!
Could you try this instead?
diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake
index 078c031..4c98a6d 100644
--- a/Modules/FindQt4.cmake
+++ b/Modules/FindQt4.cmake
@@ -965,13 +965,17 @@ if (QT_QMAKE_EXECUTABLE AND QTVERSION)
macro(_qt4_add_target_depends_internal _QT_MODULE _PROPERTY)
if (TARGET Qt4::${_QT_MODULE})
foreach(_DEPEND ${ARGN})
+set(_VALID_DEPENDS 1)
if (NOT TARGET Qt4::Qt${_DEPEND})
- message(FATAL_ERROR _qt4_add_target_depends invoked with invalid
arguments)
+ set(_VALID_DEPENDS 0)
endif()
-set_property(TARGET Qt4::${_QT_MODULE} APPEND PROPERTY
- ${_PROPERTY}
- Qt4::Qt${_DEPEND}
-)
+if (_VALID_DEPENDS)
+ set_property(TARGET Qt4::${_QT_MODULE} APPEND PROPERTY
+${_PROPERTY}
+Qt4::Qt${_DEPEND}
+ )
+endif()
+set(_VALID_DEPENDS)
endforeach()
endif()
endmacro()
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QT4 Module Patch Request
Nicolas Tisserand wrote: Hi, Date: Tue, 26 Feb 2013 20:25:42 +0100 From: Stephen Kelly steve...@gmail.com Subject: Re: [CMake] QT4 Module Patch Request To: cmake@cmake.org Message-ID: kgj27j$m0m$1...@ger.gmane.org Content-Type: text/plain; charset=ISO-8859-1 Could you try this instead? Yes, that works equally well! I've added a similar commit to the next branch: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d5230d Thanks for testing master! 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suggestions needed for handling Fedora UsrMove
Orion Poplawski wrote: In current Fedora, /sbin,/bin, and /lib are symbolic links to /usr/sbin, /usr/bin, and /usr/lib. This causes problems such as the one outlined here: https://bugzilla.redhat.com/show_bug.cgi?id=917407 where find_package(PKG NO_MODULE) will find PKGConfig.cmake in /lib/pkg/ instead of /usr/lib/pkg/, and perhaps then make the erroneous assumption that everything is based in / rather than /usr. I think some of this is caused by cmake being found in /bin/ if /bin in earlier than /usr/bin in the PATH. I'm looking for suggestions as to how to handle this on a distro wide level (as I'm a packager of cmake for Fedora). Perhaps some way to tell cmake to start with /usr as a prefix first rather than basing off of PATH or where cmake is first found? We discussed that over the last few months. All relevant information should be in these threads: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5327 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5868/focus=5907 The solution is in cmake master now: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5868/focus=6311 I guess your options are to wait for cmake 2.8.11 to be released (in a few weeks) or backport a similar patch to your current cmake version package (then re-build all packages using that patched cmake to generate the config files). For clarity, this is not related to cmake being found in /bin. It's about where the Config.cmake files are found. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] how to export header-only library (2.8.11)?
Matthew Woehlke wrote: Now that 2.8.11 supports interface include_directories on targets, is there a way to create a library target that can be exported that has no actual library, but *does* define interface include_directories? That won't be possible in 2.8.11, but will be possible in the future. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools
Alexander Neundorf wrote: On Thursday 14 March 2013, Robert Maynard wrote: These changes will be in 2.8.11 RC1 for you to test out. Cool :-) Before I merge it into next, could you have a look at the TI_DSP_to_TI branch, I had some git trouble and I'm not quite sure everything is in this branch as it should... You have a copy of a commit from Peter in your branch which shouldn't be there. Run 'git rebase origin/master' and check the result with gitk before merging. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to using 'conditional statements at generate time'?
Yuchen Deng wrote: hi, there! I was reading the release log in here: http://www.kitware.com/news/home/browse/CMake? 2012_11_07CMake+2.8.10+Just+Released Add see the parts: Generator expressions, which are used to introduce conditional statements at generate time rather than at CMake compile time, are now available in more contexts, *notably in the INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS target properties.* There are also new generator expressions available in the 2.8.10 release. In many times, I have to add more target in one CMakeLists.txt. My question: How to use for INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS target properties ? Any examples? tests? or docs? Thanks! Hi there, I'm impressed that you ask for the tests for this stuff. That's where I look too when I want to find out how to use something. :) The relevant tests in the cmake repo are in Tests/CMakeCommands/* Tests/GeneratorExpressions Tests/CompileDefinitons/target_prop Tests/IncludeDirectories/TargetIncludeDirectories Tests/ExportImport The target_include_directories is the more 'high level' API around the more low-level INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS properties in the other tests. See the docs like cmake --help-property INTERFACE_INCLUDE_DIRECTORIES cmake --help-property INTERFACE_COMPILE_DEFINITIONS cmake --help-variable CMAKE_BUILD_INTERFACE_INCLUDES (note that this will be renamed to CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE soon) See also more information here: http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/7778 Thanks for trying the stuff out, 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] does target_include_directories support SYSTEM?
Matthew Woehlke wrote:
See subject. I have a target that is the compiled sources from some
stuff generated by Google Protobuf, which means using the headers also
depend on ${PROTOBUF_INCLUDE_DIRS}. I would like to have this be a
SYSTEM include... is this supported?
Nope. It would be possible to add, but it requires refactoring the cmake C++
source and the way system dirs are handled.
Also, is there a way to treat all interface include directories of
imported targets as SYSTEM?
Nope.
Please file bug reports if you want to track these features.
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Qt5
Alok Govil wrote: Hi all, I had Qt4 functional with CMake, but cannot get Qt5 to work (have upgraded to the latest version of CMake). I have tried everything I could find including a prior post on the Cmake mailing list, to no avail. Here's another relevant link :) : http://www.macieira.org/blog/2012/05/doesnt-work-doesnt-work/ You haven't told us what the problem is. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Usage of export(PACKAGE ...)
Jean-Christophe Fillion-Robin wrote: Hi Folks, I would like to discussed the usable of export(PACKAGE ...) statement. Based on my experience, it turns out that exporting the build tree in the system package registry is a bad idea when building the same package multiple time as it is done on a dashboard client or a developer workstation trying out multiple configurations. Indeed, when find_package is used in CONFIG (or NO_MODULE) mode, by default CMake will search into the CMAKE_SYSTEM_PACKAGE_REGISTRY and will resolve to an already generated build tree instead of the one passed using PROJECT_NAME_DIR. What do you think ? Should we deprecate the use of export(PACKAGE ..) or add a warning in the documentation ? Reference: http://www.cmake.org/cmake/help/v2.8.10/cmake.html#command:export I filed http://public.kitware.com/Bug/view.php?id=13747 about this some time ago, but I haven't tried to reproduce it since, and I don't have a testplan for it. Could you describe a reliable way to reproduce the problem? 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMakeModules repository at GitHub?
David Cole wrote: Two rules: - Project config files can only go *with* the project. (VTK and ITK have them. Qt 5 has one. KDE uses them... All the cool projects have one. :-) There is an additional note for this rule: - If a Config file is created, it must be created independent of the buildsystem used by the project. pcre can be built with autotools or with cmake. There is little point in adding some install(EXPORT) lines to the CMakeLists.txt files because the config files would not be created when building pcre with autotools. In that case, some external script would have to be used to create the files. llvm also creates cmake config files I think, but they also have an autotools buildsystem (which as far as I know does not create the config files). So, in that sense they're 'breaking the rule' because creating a useful package depends on building them with cmake anyway. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INSTALL_INTERFACE question
clin...@elemtech.com wrote:
I'm playing with some of the new cmake 2.8.11 features and an example I
saw had this:
set_property(TARGET foo PROPERTY
INTERFACE_INCLUDE_DIRECTORIES
$BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR};
${CMAKE_CURRENT_SOURCE_DIR}
$INSTALL_INTERFACE:${CMAKE_INSTALL_PREFIX}/include
)
I can see it put the expanded version of ${CMAKE_INSTALL_PREFIX}/include
in my export file, but I want it to be relocatable. For example, if I use
the CPack ZIP generator, the files can be unzipped anywhere. If I replace
it with $INSTALL_INTERFACE:include , it complains about it being a
relative path.
Indeed. The $INSTALL_PREFIX generator expression was created to address
this issue. It expands to the ${_IMPORT_PREFIX}. Where did you see the
example above? In an old commit message? It doesn't seem to be in the code:
$ git grep INSTALL_PREFIX./include
Tests/ExportImport/Export/CMakeLists.txt:$INSTALL_INTERFACE:
$INSTALL_PREFIX/include/${_libName}
Tests/ExportImport/Export/CMakeLists.txt: INTERFACE_INCLUDE_DIRECTORIES
$INSTALL_INTERFACE:$INSTALL_PREFIX/include/testSharedLibRequired
Tests/ExportImport/Export/CMakeLists.txt: INTERFACE_INCLUDE_DIRECTORIES
$INSTALL_INTERFACE:$INSTALL_PREFIX/include/testSharedLibDepends
Tests/RunCMake/GeneratorExpression/BadInstallPrefix.cmake:
$INSTALL_PREFIX/include
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INSTALL_INTERFACE question
Stephen Kelly wrote: Where did you see the example above? In an old commit message? It doesn't seem to be in the code: Ah, I found and fixed it on the wiki page: http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 2.8.11-rc3 generator expression error (was: Cannot restore timestamp error on Windows)
Brad King wrote: On 04/24/2013 09:11 AM, Paul Smith wrote: On Wed, 2013-04-24 at 09:02 -0400, John Drescher wrote: I installed it and it ran one time and I didn't see the error, but it's intermittent so that's not definitive. Unfortunately one of my cmake files failed (later on; this is a cmake file from a smaller sub-project): CMake Error at CMakeLists.txt:190 (TARGET_LINK_LIBRARIES): Error evaluating generator expression: $TARGET_PROPERTY: $$CONFIG:DEBUG:php5ts_debug,INTERFACE_INCLUDE_DIRECTORIES $TARGET_PROPERTY:tgt,prop expression requires a non-empty target name. I'm not clear on whether this is intermittent or does it occur for you every time you run cmake for the project? Ideas? None yet, but I'm in a rush at the moment. The package I'm trying to build is here, FWIW: https://github.com/nuodb/nuodb-php-pdo The CMakeLists.txt file is here: https://github.com/nuodb/nuodb-php-pdo/blob/master/CMakeLists.txt I cloned that project but I'm unable to reproduce the generator expression error message with the Visual Studio 10 generator. I tried on linux, but nuodb doesn't seem to be available via aptitude (so it fails at configure time), and I don't have time to dig into it right now. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 2.8.11-rc3 generator expression error
Brad King wrote: $ cmake .. -GXcode ... CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $TARGET_PROPERTY:$$CONFIG:DEBUG:A,INTERFACE_INCLUDE_DIRECTORIES $TARGET_PROPERTY:tgt,prop expression requires a non-empty target name. ... I haven't had time to investigate fully, but this patch should 'fix' the problem: diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx index 66c22b1..8174ac2 100644 --- a/Source/cmTarget.cxx +++ b/Source/cmTarget.cxx @@ -2947,8 +2947,8 @@ std::vectorstd::string cmTarget::GetIncludeDirectories(const char *config) } cmGeneratorExpression ge(it-Backtrace); cmsys::auto_ptrcmCompiledGeneratorExpression cge = ge.Parse( - $TARGET_PROPERTY: + - it-Value + ,INTERFACE_INCLUDE_DIRECTORIES); + $$BOOL: + it-Value + :$TARGET_PROPERTY: + + it-Value + ,INTERFACE_INCLUDE_DIRECTORIES); this-Internal- CachedLinkInterfaceIncludeDirectoriesEntries.push_back( new cmTargetInternals::IncludeDirectoriesEntry(cge, I'll investigate later to see if it's the right fix and why. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 2.8.11-rc3 generator expression error
Brad King wrote: On 04/25/2013 03:34 AM, Stephen Kelly wrote: I haven't had time to investigate fully, but this patch should 'fix' the problem: [snip] I'll investigate later to see if it's the right fix and why. Great! I've turned that patch into this commit: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=de9d4a63 See commit message for an explanation that makes sense to me. The commit message is correct, but it's not the whole story. We also need to validate the it-Value as a target name acceptable to TARGET_PROPERTY. I've pushed the fix-multi-config-tll-include-dirs branch to my clone. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] default CONFIGURATIONS in cygwin
Lloyd wrote: Hi, I am studying to compile an application using CMake in Cygwin. I am installing a file using the install command based on the value of CONFIGURATIONS variable. May I know the default configuration (debug, release) in cygwin I get Debug folders in the build directory when I build the same project with visual studio, but in the cygwin build directory, no Debug or Release folders are created! I haven't tried, and I don't know anything about cygwin, but I'm reminded of http://public.kitware.com/Bug/view.php?id=12301 Is it similar? 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] turning inverting dashboard interpretation of FATAL_ERRORs at cmake
Matthias Kretz wrote: On Thursday 25 April 2013 10:30:14 Bill Hoffman wrote: On 4/25/2013 10:05 AM, Matthias Kretz wrote: I'm not sure we're talking about the same thing. I'm talking about ctest_configure - i.e. before build or tests. IIUC you're talking about regex matching at ctest_test? But, if you have a FATAL_ERROR in the configure step, no build files will be created and you won't even get a build of the software to test. Which is the correct behavior. And I'd like my dashboard to tell me that it works. Without building or testing. The test in this case consists of making sure that my cmake script aborts with the right error message. See the RunCMake tests in the cmake test suite. 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://www.cmake.org/mailman/listinfo/cmake
[CMake] Building multiple configurations with Xcode?
Hi, I am investigating https://bugreports.qt-project.org/browse/QTBUG-30938 and I wanted to see what cmake exports when it export() is used with a framework target. I created a shared library and ran cmake with -GXcode, then cmake --build ., but it seems to only create a release library. I thought Xcode generated rules for multiple configurations? Do I need to do something extra for that to be done? Thanks, Steve. cmake_minimum_required(VERSION 2.8) project(cmake_framework_target) include(GenerateExportHeader) set(CMAKE_INCLUDE_CURRENT_DIR ON) add_library(other SHARED lib.cpp) generate_export_header(other) set_property(TARGET other PROPERTY FRAMEWORK 1) install(TARGETS other RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib FRAMEWORK DESTINATION framework ) -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building multiple configurations with Xcode?
Stephen Kelly wrote: and I wanted to see what cmake exports when it export() is used with a framework target. I created a shared library and ran cmake with -GXcode, then cmake --build ., but it seems to only create a release library. I thought Xcode generated rules for multiple configurations? Do I need to do something extra for that to be done? I found that I need to use cmake . --build --config Debug or --config Release to build a particular configuration. However, the debug and release names are the same. I also ran cmake with -DCMAKE_DEBUG_POSTFIX=Debug but that didn't make any difference. I'm not familiar with the way things are done on mac. Any ideas? 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building multiple configurations with Xcode?
Stephen Kelly wrote: or --config Release to build a particular configuration. However, the debug and release names are the same. I also ran cmake with -DCMAKE_DEBUG_POSTFIX=Debug but that didn't make any difference. This makes a difference for non-frameworks, but does not make a difference if the FRAMEWORK property is true. Is it possible to build multi-config frameworks with cmake at all? 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building multiple configurations with Xcode?
Stephen Kelly wrote: Is it possible to build multi-config frameworks with cmake at all? I also notice that the Framework unit test uses set_target_properties(foo PROPERTIES FRAMEWORK TRUE DEBUG_POSTFIX -d ) but the debug file is called 'foo', not 'foo-d'. If I use cmake --build . --target install --config Debug cmake --build . --target install --config Release the debug and release versions overwrite each other. Does this mean it has always been broken? Has no one ever tried to create a framework using cmake? 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building multiple configurations with Xcode?
clin...@elemtech.com wrote: - Original Message - Stephen Kelly wrote: Is it possible to build multi-config frameworks with cmake at all? I also notice that the Framework unit test uses set_target_properties(foo PROPERTIES FRAMEWORK TRUE DEBUG_POSTFIX -d ) but the debug file is called 'foo', not 'foo-d'. If I use cmake --build . --target install --config Debug cmake --build . --target install --config Release the debug and release versions overwrite each other. Does this mean it has always been broken? Has no one ever tried to create a framework using cmake? In the build tree, I would expect foo not foo-d for the debug framework. And in the build tree, it is possible to differentiate the release from debug simply by having two foo.framework/foo. One will be in the Release folder and one in the Debug folder, and a Debug build will use the one from the Debug folder, while the release build will use the one from the Release folder. That indeed appears to be what happens. For the install tree, I don't see how it is known which configurations will be installed. I'm not familiar with xcode, so I assumed that if you install it would install all configurations, or you would specify which you want to install. When I use the command line I use cmake --build . --target install --config Debug so it is specified. So, I don't know what you mean here. Can you be more specific, keeping in mind I don't know xcode? Assuming there is some unavoidable reason that the configuration is not known when installing, does that mean that frameworks which contain a foo and a foo_debug can not be created by cmake? I left a comment on the original Qt bug above that he should look into using DYLD_IMAGE_SUFFIX. Is that right? 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building multiple configurations with Xcode?
clin...@elemtech.com wrote: - Original Message - clin...@elemtech.com wrote: - Original Message - Stephen Kelly wrote: Is it possible to build multi-config frameworks with cmake at all? I also notice that the Framework unit test uses set_target_properties(foo PROPERTIES FRAMEWORK TRUE DEBUG_POSTFIX -d ) but the debug file is called 'foo', not 'foo-d'. If I use cmake --build . --target install --config Debug cmake --build . --target install --config Release the debug and release versions overwrite each other. Does this mean it has always been broken? Has no one ever tried to create a framework using cmake? In the build tree, I would expect foo not foo-d for the debug framework. And in the build tree, it is possible to differentiate the release from debug simply by having two foo.framework/foo. One will be in the Release folder and one in the Debug folder, and a Debug build will use the one from the Debug folder, while the release build will use the one from the Release folder. That indeed appears to be what happens. But, I personally don't see a problem with there being a foo.framework/foo and a foo-d.framework/foo-d. At install time, they would not overwrite each other and the export file would need to list both of them. Or Release/foo.framework/foo Debug/foo.framework/foo-d for a presumably smaller change. I don't know about export(), but install(EXPORT) is already fine. It installs multiple targets-config.cmake files, where each one would reference the correct IMPORTED_LOCATION_CONFIG. I just assumed that was already implemented. You might be able to tell me if there's some other location/file in a framework that would break though? (update: I think I understood below) For the install tree, I don't see how it is known which configurations will be installed. I'm not familiar with xcode, so I assumed that if you install it would install all configurations, or you would specify which you want to install. Xcode works in one configuration at a time. The install target is the same way, by installing only one configuration at a time. Ok, so you specify the configuration you want *this time? Then the configuration is known, right? We don't need to know all configurations that will be installed because of the multiple targets files. When I use the command line I use cmake --build . --target install --config Debug so it is specified. That one configuration was specified, yes. But it isn't known if the Release one will also be installed. If it is known they are both being installed, and one wanted them to both go into the same framework, then the debug one can be renamed to and the burden put on the user to specify DYLD_IMAGE_SUFFIX to run their application with the debug library. renamed to foo_debug ? I don't know for certain, but it seems that that is the common way of creating these things, right? If only the Debug configuration is installed, and it was still renamed, you'd have a broken framework. Ah, I think I understand now. If I install both debug and release, then I get foo.framework/foo foo.framework/foo_debug but if I install only the debug version, then I get only foo.framework/foo_debug And, you're saying that the framework system is not smart enough to work with that because the non-_debug version is missing? It doesn't just append the DYLD_IMAGE_SUFFIX on the name of the framework, and after locating the framework use that as the name of the file? So, I don't know what you mean here. Can you be more specific, keeping in mind I don't know xcode? The behavior is basically the same as visual studio, if you know that, I'm afraid I never used it extensively or for c++. with the addition of this framework concept. While the whole build system supports multiple configurations, the user is only in one configuration at a given time. ... and the user can only install/create their own frameworks as one configuration at a time? The user can't easily create/install multi-config frameworks? I left a comment on the original Qt bug above that he should look into using DYLD_IMAGE_SUFFIX. Is that right? That is the correct response in the context of Qt. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building multiple configurations with Xcode?
clin...@elemtech.com wrote: Or Release/foo.framework/foo Debug/foo.framework/foo-d Ok, but the framework version of the linker flags -L,-l are used like this: -F/path/to/framework -framework foo which result in the linker would look for this file /path/to/framework/foo.framework/foo So, Debug/foo.framework/foo-d is not a valid framework. CMake seems to already be putting the framework in a Debug/Release folder. Does that mean that they are not valid frameworks in the build dir? Does that mean they can't be used from the build dir at all? What if you use -F/path/to/framework/Debug ? For the install tree, I don't see how it is known which configurations will be installed. I'm not familiar with xcode, so I assumed that if you install it would install all configurations, or you would specify which you want to install. Xcode works in one configuration at a time. The install target is the same way, by installing only one configuration at a time. Ok, so you specify the configuration you want *this time? Then the configuration is known, right? We don't need to know all configurations that will be installed because of the multiple targets files. When I use the command line I use cmake --build . --target install --config Debug so it is specified. That one configuration was specified, yes. But it isn't known if the Release one will also be installed. If it is known they are both being installed, and one wanted them to both go into the same framework, then the debug one can be renamed to and the burden put on the user to specify DYLD_IMAGE_SUFFIX to run their application with the debug library. renamed to foo_debug ? I don't know for certain, but it seems that that is the common way of creating these things, right? If only the Debug configuration is installed, and it was still renamed, you'd have a broken framework. Ah, I think I understand now. If I install both debug and release, then I get foo.framework/foo foo.framework/foo_debug but if I install only the debug version, then I get only foo.framework/foo_debug And, you're saying that the framework system is not smart enough to work with that because the non-_debug version is missing? It doesn't just append the DYLD_IMAGE_SUFFIX on the name of the framework, and after locating the framework use that as the name of the file? With the -F/-framework link flags, the linker looks for foo.framework/foo The DYLD_* variables are used by the dynamic loader at runtime and do not affect the linker. I see. I wonder if this leaves us in a solvable situation. ... and the user can only install/create their own frameworks as one configuration at a time? The user can't easily create/install multi-config frameworks? Yes. Its a separate step to handle multiple configurations, like you did earlier. cmake --build . --target install --config Debug cmake --build . --target install --config Release And yes, with frameworks, there is the issue of overwriting files. I don't really care about this problem, yet. Only on windows is a debug library required for regular development because of the configuration specific C/C++ runtime libraries. If I made a framework for other people to use, and if for some reason they wanted to debug my framework, they could simply compile a debug only version and link with that. So I don't see a big need for both a release and debug framework. Closed source is not common/relevant? In the past, when I've had to debug the Qt libraries on Mac, I've either made a debug only build, or modified the frameworks. The modification was because Qt uses the same _debug suffix as the whole system, and I don't want the debug version of all of the system libraries because it is way too slow. So anyway, for me, this is a very low priority problem compared to other cmake issues. Right. The reporter at https://bugreports.qt-project.org/browse/QTBUG-30938 raises a reason that DYLD_IMAGE_SUFFIX doesn't work for him anyway. I wonder what qmake does here. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug in cmake 2.8.11 when detecting sgemm function from MKL 11.0
Bogdan Cristea wrote: Hi I have noticed that the latest cmake release, 2.8.11, does not detect sgemm using check_function_exists macro from mkl_rt.lib library. The error message says; Cannot find C:\Program.obj It seems to me that the paths with spaces are no longer handled correctly. Installing the previous version, 2.8.10, everything works as expected. Also I have noticed that the 2.8.11 installer seems to create two entries in Windows program database. I am using Windows 8 x86_64 Can you create a minimal testcase? I'm not familiar with sgemm or MKL. Can you say more? What makes you think it is related to whitespace? 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug in cmake 2.8.11 when detecting sgemm function from MKL 11.0
Bill Hoffman wrote: On 5/23/2013 1:48 PM, Stephen Kelly wrote: Hi I have noticed that the latest cmake release, 2.8.11, does not detect sgemm using check_function_exists macro from mkl_rt.lib library. The error message says; Cannot find C:\Program.obj It seems to me that the paths with spaces are no longer handled correctly. Installing the previous version, 2.8.10, everything works as expected. Also I have noticed that the 2.8.11 installer seems to create two entries in Windows program database. I am using Windows 8 x86_64 Can you create a minimal testcase? I'm not familiar with sgemm or MKL. Can you say more? What makes you think it is related to whitespace? Because it is almost certainly: c\Program Files\. Instead of c:\Program.obj. Right, but I think more info is needed, so in the hope of getting useful information, I'm just asking more questions - even obvious questions. Does this problem happen with all libraries in a directory with whitespace? 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug in cmake 2.8.11 when detecting sgemm function from MKL 11.0
Brad King wrote: On 05/24/2013 04:24 PM, Brad King wrote: It does not individually re-quote the library names so when the generated CMakeLists.txt file is parsed it separates on spaces. Fixed: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e65ef08b Great, thanks! -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug in cmake 2.8.11 when detecting sgemm function from MKL 11.0
Brad King wrote: On 05/24/2013 04:24 PM, Brad King wrote: It does not individually re-quote the library names so when the generated CMakeLists.txt file is parsed it separates on spaces. Fixed: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e65ef08b This commit causes the build of kde-workspace to fail: http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/7858 The problem is that FindXKB.cmake uses a space separated list, which happened to work before your commit. https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/cmake/modules/FindXKB.cmake 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake 2.8.12-rc1 Released
Alexander Neundorf wrote:
On Tuesday 20 August 2013, Robert Maynard wrote:
Introduced CMake Policy 21:
It is now an error to use relative paths to include_directories.
Why is this necessary ?
The documentation for this policy says:
The base path for such relative entries is not well defined.
I don't understand this.
Why isn't it simply interpreted as relative to ${CMAKE_CURRENT_SOURCE_DIR}
in the CMakeLists.txt where the property is set ?
include_directories(), link_directories() and I think more or less all
other commands interpret relative paths as relative to
${CMAKE_CURRENT_SOURCE_DIR}.
I think the bug is in the release notes entry.
This relates to commit eabefa8b02b399b00aea83185b6b364ab5b6aa3d.
Relative paths can still be used with the include_directories() command.
This relates mostly to using set_property and using generator expressions
where the base path is not well-defined until generate-time.
Maybe a better release notes entry would be
- It is now an error to add relative paths to the INCLUDE_DIRECTORIES target
property.
Thanks,
Steve.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Configuration specific COMPILE_FLAGS?
Giordano Khouri wrote: I'm surprised to see that there's no configuration specific COMPILE_FLAGS. Please correct me if I'm wrong. Correct, but not the whole story. When you upgrade to CMake 2.8.12 you can use the COMPILE_OPTIONS target property. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3507d5a Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake-2.8.12: generator expression error when linker flags have comma
Jed Brown wrote: I just upgraded from cmake-2.8.11.2 to 2.8.12 and now get errors when a comma ',' appears in a linker flag. Test case below. Note that this is but one of many reasons for a comma to appear in linker flags. I've pushed a fix candidate: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3eeb83d147030 Remember that the way to avoid bugs like this in the release is to test a release candidate. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake-2.8.12: generator expression error when linker flags have comma
Jed Brown wrote:
Stephen Kelly steve...@gmail.com writes:
Jed Brown wrote:
I just upgraded from cmake-2.8.11.2 to 2.8.12 and now get errors when a
comma ',' appears in a linker flag. Test case below. Note that this is
but one of many reasons for a comma to appear in linker flags.
I've pushed a fix candidate:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3eeb83d147030
Thanks. Did the test case here really reproduce the problem on your
end? Putting essentially that line
target_link_libraries(staticlib1 LINK_PRIVATE
-L${CMAKE_CURRENT_BINARY_DIR} -Wl,--start-group -lstaticlib3
-Wl,--end-group)
in my test case did not trigger the error.
Yes, it produces the problem for me. Please try the unit test, or post a
full example using that line which does not show the problem.
I guess this will be in 2.8.12.1, whenever that is released?
I assume so too.
Remember that the way to avoid bugs like this in the release is to test a
release candidate.
None of my current projects use CMake. I encountered this issue while
updating an interface to someone else's project that uses CMake. I
reduced the test case to rule out the possibility that it was a usage
problem on his part and to make sure it was easy for you to reproduce so
that it could be fixed quickly, but I don't see it as my responsibility
to test release candidates of software that I don't use.
Ok, thanks for reporting!
Steve.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake policy CMP0022 error
Clinton Stimpson wrote: I have a target where I do this: SET_TARGET_PROPERTIES(mytarget PROPERTIES LINK_INTERFACE_LIBRARIES ) to hide 3rd party libraries from the link interface. When I do if(APPLE) CMAKE_MINIMUM_REQUIRED(VERSION 2.8.12) endif() I get an error at generate time. This is different than my previous experiences with cmake policies. Based on past experiences, I expected to see a warning if I had CMAKE_MINIMUM_REQUIRED(VERSION 2.8) but used CMake 2.8.12 which introduced CMP0022. You might have wrong understanding of policies. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6d50d0197a5 Your use of cmake_minimum_required(VERSION 2.8.12) requests the non-backward compatible behavior. But in this case, I don't see a warning. The error I get with CMAKE_MINIMUM_REQUIRED(VERSION 2.8.12) is: CMake Error in .../CMakeLists.txt: Target mytarget has policy CMP0022 enabled, but also has old-style LINK_INTERFACE_LIBRARIES properties populated, but it was exported without the EXPORT_LINK_INTERFACE_LIBRARIES to export the old-style properties When I read the output from cmake --help-policy CMP0022, its not clear to me why I'm getting the error. 2.8.12 introduced a INTERFACE_LINK_LIBRARIES property, which should be used instead of LINK_INTERFACE_LIBRARIES. The policy makes the INTERFACE_LINK_LIBRARIES property ignored until it is set to NEW. So when you do this: SET_TARGET_PROPERTIES(mytarget PROPERTIES LINK_INTERFACE_LIBRARIES ) you could consider doing this instead: SET_TARGET_PROPERTIES(mytarget PROPERTIES INTERFACE_LINK_LIBRARIES ) or just use target_link_libraries(mytarget PRIVATE hiddenlib) which has the same effect. PRIVATE means 'hide from the link interface'. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake policy CMP0022 error
Clinton Stimpson wrote: I'm trying to point out that I did not get a warning when I was using cmake_minimum_required(VERSION 2.8) set_target_properties(mytarget PROPERTIES LINK_INTERFACE_LIBRARIES ) with CMake 2.8.12. That looks like a bug. The policy warning is only issued if 1) Both LINK_INTERFACE_LIBRARIES and INTERFACE_LINK_LIBRARIES are set on a single target (either by using set_property or by using the various target_link_libraries signatures). 2) You export() or install(EXPORT) a target which has LINK_INTERFACE_LIBRARIES set, but which does not use the new EXPORT_LINK_INTERFACE_LIBRARIES option to those commands to cause it to be exported to the targets file, even though the policy is set to NEW. There may be a bug there, or a chance to emit a warning we're not currently emitting. Please file a bug with a testcase if that is the case. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
