[cmake-developers] [CMake 0012054]: FindJava.cmake too noisy on second run
The following issue has been SUBMITTED. == http://cmake.org/Bug/view.php?id=12054 == Reported By:Rolf Eike Beer Assigned To: == Project:CMake Issue ID: 12054 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-04-07 07:11 EDT Last Modified: 2011-04-07 07:11 EDT == Summary:FindJava.cmake too noisy on second run Description: Other Find*.cmake modules (like Qt) don't output anything on second run. FindJava.cmake does. Steps to Reproduce: PROJECT(JavaTest NONE) CMAKE_MINIMUM_REQUIRED(VERSION 2.8) FIND_PACKAGE(Java REQUIRED) FIND_PACKAGE(Java REQUIRED) Additional Information: $ cmake . -- Java version 1.6.0.24 configured successfully! -- Java version 1.6.0.24 configured successfully! -- Configuring done -- Generating done -- Build files have been written to: /tmp/cmjava == Issue History Date ModifiedUsername FieldChange == 2011-04-07 07:11 Rolf Eike Beer New Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Qt Bundle Utilities/Packaging
On Thursday, April 07, 2011 10:03:45 am Mike McQuaid wrote:
On 7 April 2011 16:41, Clinton Stimpson clin...@elemtech.com wrote:
I would put it in Qt4Macros.cmake and document it in FindQt4.cmake.
Cool, ok.
I would love some other people's input in this work.
I have put some work into it already and can give you the patches I have
so far.
When I started 'using' the functions, they didn't work the way I wanted.
So what I am hoping for was input on what the CMakeLists.txt files
should contain... then maybe we can adjust the functions for installing
Qt plugins to work with that.
Here's a snippet from a CMakeLists.txt file that demonstrates how I
wanted to be able to call it. You'll notice how the functions follow
the install() command style. There is some of passing the same
arguments into each command, but at least the caller doesn't have to
formulate a different set of arguments for each function call. If there
is a totally different way to think about this, I'm open to suggestions.
===
function(install_prerequisites )
install(CODE
include(BundleUtilities)
fixup_bundle(\${app}\ \${libs}\ \${dirs}\)
)
endfunction(install_prerequisites)
include(CPack)
# install target
install(TARGETS testqt DESTINATION bin)
# install Qt plugins in a custom location
qt4_install_default_plugins(DESTINATION bin/myplugins)
# install qt.conf file with custom plugin location
qt4_install_qtconf(DESTINATION bin BUNDLE_DESTIATION . CONTENTS Plugins
myplugins)
# install prerequisites (todo, how to pass installed Qt plugins into
this function?)
install_prerequisites(TARGET testqt DESTINATION bin BUNDLE_DESTINATION .
COMPONENT Runtime)
===
Also, see attached for patch to Qt4Macros.cmake and FindQt4.cmake.
I think we can combine our work here. I guess my thoughts was to make
something even more generic, you just give it an application bundle
and paths to plugins (although you could use plugin names too using
your macros) and it would install them, fix up the package and write
the qt.conf if needed on the platform with the plugin location (e.g.
needed for Mac bundles, not for Windows). It should also know about
all the needed destinations per-platform. I guess I saw my stuff as an
extension to fixup_bundle rather than existing much outside so instead
of fixup_bundle and do_qt_stuff I would just call deploy_qt(app
plugins) and it does the rest automagically.
That could be a good way to go first. If the need arises, we could introduce
more public functions for customization.
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] ZLIB: improve message when library is found
If you do
FIND_PACKAGE(ZLIB)
you currently get the include directory printed out (usually /usr/include)
which isn't very helpful IMHO. Attached patch changes this so the library is
shown.
EikeFrom ea681ea84eb35d24952626b53ccf595cbc4e7ca4 Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer e...@sf-mail.de
Date: Thu, 7 Apr 2011 18:22:24 +0200
Subject: [PATCH] print zlib library instead of include directory
Before:
-- Found ZLIB: /usr/include (found version 1.2.3)
After:
-- Found ZLIB: /usr/lib/libz.so (found version 1.2.3)
---
Modules/FindZLIB.cmake |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Modules/FindZLIB.cmake b/Modules/FindZLIB.cmake
index 2062a7e..77f9fda 100644
--- a/Modules/FindZLIB.cmake
+++ b/Modules/FindZLIB.cmake
@@ -67,7 +67,7 @@ ENDIF()
# handle the QUIETLY and REQUIRED arguments and set ZLIB_FOUND to TRUE if
# all listed variables are TRUE
INCLUDE(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
-FIND_PACKAGE_HANDLE_STANDARD_ARGS(ZLIB REQUIRED_VARS ZLIB_INCLUDE_DIR ZLIB_LIBRARY
+FIND_PACKAGE_HANDLE_STANDARD_ARGS(ZLIB REQUIRED_VARS ZLIB_LIBRARY ZLIB_INCLUDE_DIR
VERSION_VAR ZLIB_VERSION_STRING)
IF(ZLIB_FOUND)
--
1.7.3.2
signature.asc
Description: This is a digitally signed message part.
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ZLIB: improve message when library is found
On 04/07/2011 12:24 PM, Rolf Eike Beer wrote: If you do FIND_PACKAGE(ZLIB) you currently get the include directory printed out (usually /usr/include) which isn't very helpful IMHO. Attached patch changes this so the library is shown. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0dafc0a8 Thanks! -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
On 04/06/2011 10:15 PM, Manuel Klimek wrote: For your convenience, rebased onto current head and git format-patch'ed. Thanks. I used that series to reconstruct the topic on master locally. I will review and test further when I get a chance. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Qt Bundle Utilities/Packaging
On Thu, Apr 7, 2011 at 1:17 PM, Clinton Stimpson clin...@elemtech.comwrote: On Thursday, April 07, 2011 10:29:41 am Mike McQuaid wrote: On 7 April 2011 17:17, Clinton Stimpson clin...@elemtech.com wrote: That could be a good way to go first. If the need arises, we could introduce more public functions for customization. I guess we could do what fixup_bundle and get_prerequisites do in that we have a very general function that just does stuff correctly and then more specific ones people can call for a more customisable process. Here's my (untested) work in progress: https://gist.github.com/908134 I'll probably port it to use your macros tomorrow but you probably get the gist (no pun intended) of my approach from that. It shouldn't require anything except the app arguments and the plugins (currently only direct paths but could also be the named versions like on yours) but optionally can include more libraries (should be handled but fixup_bundle, not sure if this is necessary) and the search directories (e.g. if Qt is outside the path you might pass QT_LIBRARY_DIR here). Let me know your thoughts! I have some thoughts... I think you should *always* write out a qt.conf file. The Qt libraries have hardcoded paths (used if there is no qt.conf file) and if the target machine has a Qt installation at the same location as the build machine, it could get the target machines plugins instead. These plugins are tied to a specific version and configuration of Qt, so they cannot be mixed. On Mac, the problem of a missing qt.conf is immediate on the build machine. I think we should add QT_LIBRARY_DIR to fixup_bundle()'s dirs all the time. Have you thought about letting the user supply a list of their own plugins and having the function add the default Qt plugins to that list (or a set of plugins based on the QT_USE_* variables)? Also, one frequent complaint with using these functions is the user having to do install(CODE ) and worry about escaping quotes and dollar signs. Do you think this would be a good time to address that? Absolutely: any general solution should configure a script into the build tree, and use install(SCRIPT instead to avoid the escaping madness. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Qt Bundle Utilities/Packaging
On Thu, Apr 7, 2011 at 1:23 PM, David Cole david.c...@kitware.com wrote: On Thu, Apr 7, 2011 at 1:17 PM, Clinton Stimpson clin...@elemtech.comwrote: On Thursday, April 07, 2011 10:29:41 am Mike McQuaid wrote: On 7 April 2011 17:17, Clinton Stimpson clin...@elemtech.com wrote: That could be a good way to go first. If the need arises, we could introduce more public functions for customization. I guess we could do what fixup_bundle and get_prerequisites do in that we have a very general function that just does stuff correctly and then more specific ones people can call for a more customisable process. Here's my (untested) work in progress: https://gist.github.com/908134 I'll probably port it to use your macros tomorrow but you probably get the gist (no pun intended) of my approach from that. It shouldn't require anything except the app arguments and the plugins (currently only direct paths but could also be the named versions like on yours) but optionally can include more libraries (should be handled but fixup_bundle, not sure if this is necessary) and the search directories (e.g. if Qt is outside the path you might pass QT_LIBRARY_DIR here). Let me know your thoughts! I have some thoughts... I think you should *always* write out a qt.conf file. The Qt libraries have hardcoded paths (used if there is no qt.conf file) and if the target machine has a Qt installation at the same location as the build machine, it could get the target machines plugins instead. These plugins are tied to a specific version and configuration of Qt, so they cannot be mixed. On Mac, the problem of a missing qt.conf is immediate on the build machine. I think we should add QT_LIBRARY_DIR to fixup_bundle()'s dirs all the time. Have you thought about letting the user supply a list of their own plugins and having the function add the default Qt plugins to that list (or a set of plugins based on the QT_USE_* variables)? Also, one frequent complaint with using these functions is the user having to do install(CODE ) and worry about escaping quotes and dollar signs. Do you think this would be a good time to address that? Absolutely: any general solution should configure a script into the build tree, and use install(SCRIPT instead to avoid the escaping madness. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers Why aren't Mike's replies showing up on the list? Mike, are you subscribed to the CMake developers list? ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Small patch to support build-setting conditions in XCode
On 04/05/2011 10:05 AM, Johan Björk wrote: How about this one. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c519bb2b Thanks, -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
