[cmake-developers] [CMake 0013785]: INSTALL command does not support a QUIET/SILENT option
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13785 == Reported By:Emmanuel Blot Assigned To: == Project:CMake Issue ID: 13785 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-12-12 10:41 CET Last Modified: 2012-12-12 10:41 CET == Summary:INSTALL command does not support a QUIET/SILENT option Description: It would be very nice if there was a way to force the INSTALL() command not to print what it is doing: -- Installing: /Users/eblot/Source/... -- Up-to-date: /Users/eblot/Sources/... ... Rationale: When performing build+install in one step, install verbosity is so long that important information, such as build warnings, are scrolled out from the terminal viewport and may remain unnoticed. I understand that people are likely to want INSTALL() to be verbose, but a simple option such as INSTALL(... QUIET ...) would be nice when these traces are not wanted. == Issue History Date ModifiedUsername FieldChange == 2012-12-12 10:41 Emmanuel Blot New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013786]: function() set(PARENT_SCOPE) buggy: very surprising warn-uninitialized inconsistency for (non-)empty values
The following issue has been SUBMITTED.
==
http://www.itk.org/Bug/view.php?id=13786
==
Reported By:Andreas Mohr
Assigned To:
==
Project:CMake
Issue ID: 13786
Category: CMake
Reproducibility:always
Severity: major
Priority: high
Status: new
==
Date Submitted: 2012-12-12 05:01 EST
Last Modified: 2012-12-12 05:01 EST
==
Summary:function() set(PARENT_SCOPE) buggy: very surprising
warn-uninitialized inconsistency for (non-)empty values
Description:
I tried to get all my code free of issues,
thus I enabled --warn-uninitialized.
I was very surprised to find that initialization state of a function result
(PARENT_SCOPE) variable is being very negatively influenced by the value of the
passed variable being empty vs. non-empty,
as can be gathered from the sample below warning about result_empty yet properly
*not* warning about result_non_empty.
This should emphatically _not_ be the case - a result variable should *always*
get properly initialized (instantiated) in outer scope, no frn' matter which
value it may happen to get assigned.
And it's not a this variable already exists in outer scope vs. does not exist
-- problem issue: when assigning non-empty values the outer-scope variable
*does* get created, yet not for empty ones -- BUG.
Note that pre-initializing the result var to prior to invoking the function
does successfully silence the initialization warning.
And note that doing this initialization with a non-empty value and subsequently
calling the function *does* let the function reset the variable to empty - IOW
the variable *does* get assigned by the function in *this* case - just not if it
didn't exist previously!
Happening on both Win7 2.8.10.2 and RHEL5 2.8.8.
Severity major and prio high since it's a foundation-shattering inconsistency ;)
Given this bug it's impossible to get one's code warning-free (when making use
of clean result-use-only variable getter functions which happen to return empty
values in certain conditions).
A mere not succeeding in getting the code warning-free is a rather benign
concern - some actively disrupting bug scenarios due to this issue might be
conceivable, too.
Thanks!
Steps to Reproduce:
cmake_minimum_required(VERSION 2.8)
function(getter _result)
set(result_ ${desired_result})
set(${_result} ${result_} PARENT_SCOPE)
endfunction(getter _result)
#set(result_empty bye, cruel world) # toggle this!
set(desired_result )
getter(result_empty)
set(desired_result non-empty)
getter(result_non_empty)
message(result_empty ${result_empty}, result_non_empty ${result_non_empty}.)
Additional Information:
$ cmake --warn-uninitialized .
Warn about uninitialized values.
CMake Warning (dev) at
/home/amoh/privat/cmake_tests/bug_function_result_uninitialized_warning/CMakeLists.txt:14:
uninitialized variable 'result_empty'
This warning is for project developers. Use -Wno-dev to suppress it.
result_empty , result_non_empty non-empty.
-- Configuring done
-- Generating done
==
Issue History
Date ModifiedUsername FieldChange
==
2012-12-12 05:01 Andreas Mohr New Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013787]: Wrong default value of CPACK_PACKAGE_INSTALL_REGISTRY_KEY
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13787
==
Reported By:Jesus Malo Poyatos
Assigned To:
==
Project:CMake
Issue ID: 13787
Category: CPack
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-12-12 06:54 EST
Last Modified: 2012-12-12 06:54 EST
==
Summary:Wrong default value of
CPACK_PACKAGE_INSTALL_REGISTRY_KEY
Description:
As far as I could found, the default value of CPACK_PACKAGE_INSTALL_REGISTRY_KEY
should be ${CPACK_PACKAGE_NAME} ${CPACK_PACKAGE_VERSION} (see
http://www.cmake.org/pipermail/cmake/2010-September/039663.html), however if you
look at CPack.cmake, you will find the following (line 381):
cpack_set_if_not_set(CPACK_PACKAGE_INSTALL_REGISTRY_KEY
${CPACK_PACKAGE_INSTALL_DIRECTORY})
Is it intentionally?
BTW, the documentation of CPACK_PACKAGE_INSTALL_REGISTRY_KEY is incomplete (no
default value explained) at
http://www.cmake.org/cmake/help/v2.8.10/cpack.html#variable:CPACK_PACKAGE_INSTALL_REGISTRY_KEY
==
Issue History
Date ModifiedUsername FieldChange
==
2012-12-12 06:54 Jesus Malo PoyatosNew Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] transitive -I and -D usage requirements (was: Policy for INTERFACE_LINK_LIBRARIES)
On 12/09/2012 08:48 AM, Stephen Kelly wrote: I think the 'Setting include directories via target_link_libraries() ?' thread needs to be concluded first (with reasoning), as that affects everything else. While thinking about my next response to that discussion I read your wip-target-interface in more detail to look at handling of include dirs and compile defs. Can you explain what the commit Handle INTERFACE properties transitively for includes and defines is doing please? What is transitive in that implementation? Later in the commit Add includes and compile definitions with target_link_libraries I see propagation of INTERFACE_INCLUDE_DIRECTORIES into the implementation INCLUDE_DIRECTORIES of the target. However, it is not transitive through the link interface closure. Since the link interface closure isn't known until generate time when the full link interface generator expressions can be evaluated, I do not think we can compute the full include directories or compile definitions until then either. When a dependency is put in the link interface of a shared library that means that clients including headers from the shared library may get headers from the dependency too. Otherwise there is no way the client could get direct references to symbols from the dependency and it would not need to be in the link interface. Once a dependency is in the link interface, even transitively, clients need the -I and -D flags for it. Therefore we need to get them from the link interface closure, and it cannot be done until generate time. Thoughts? -Brad P.S. I'm not asking you to update the implementation in your branch yet, just to comment on my observations above. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Tests for PRE_BUILD | PRE_LINK | POST_BUILD
Ah, I had some goofy unicode character in my shell that was preventing the
grep search to work properly.
With the correct stuff I see coverage for PRE_BUILD and POST_BUILD, but not
PRE_LINK. I'm seeing problems with PRE_LINK not working in VS 2010, so I
wanted to see if it was actually being tested.
[5343] Tests $ find . -name *.cmake -o -name CMakeLists.txt -print0 |
xargs -0 grep -n --color PRE_BUILD
./CMakeLib/CMakeLists.txt:28:PRE_BUILD COMMAND ${CMAKE_COMMAND} -E
make_directory ${CMAKE_CFG_INTDIR}
./Complex/Executable/CMakeLists.txt:91:add_custom_command(TARGET complex
PRE_BUILD
./Complex/Executable/CMakeLists.txt:94:add_custom_command(TARGET complex
PRE_BUILD
./Complex/Library/CMakeLists.txt:78:add_custom_command(TARGET
CMakeTestLibraryShared PRE_BUILD
./Complex/Library/CMakeLists.txt:81:add_custom_command(TARGET
CMakeTestLibraryShared PRE_BUILD
./ComplexOneConfig/Executable/CMakeLists.txt:91:add_custom_command(TARGET
complex PRE_BUILD
./ComplexOneConfig/Executable/CMakeLists.txt:94:add_custom_command(TARGET
complex PRE_BUILD
./ComplexOneConfig/Library/CMakeLists.txt:78:add_custom_command(TARGET
CMakeTestLibraryShared PRE_BUILD
./ComplexOneConfig/Library/CMakeLists.txt:81:add_custom_command(TARGET
CMakeTestLibraryShared PRE_BUILD
./CTestTestMemcheck/CMakeLists.txt:13: PRE_BUILD
COMMAND ${CMAKE_COMMAND} -E make_directory ${CMAKE_CFG_INTDIR}
./CustomCommand/CMakeLists.txt:113: TARGET TDocument PRE_BUILD
[5344] Tests $ find . -name *.cmake -o -name CMakeLists.txt -print0 |
xargs -0 grep -n --color POST_BUILD
./Complex/Executable/CMakeLists.txt:97:add_custom_command(TARGET complex
POST_BUILD
./Complex/Executable/CMakeLists.txt:100:add_custom_command(TARGET complex
POST_BUILD
./Complex/Library/CMakeLists.txt:84:add_custom_command(TARGET
CMakeTestLibraryShared POST_BUILD
./Complex/Library/CMakeLists.txt:87:add_custom_command(TARGET
CMakeTestLibraryShared POST_BUILD
./ComplexOneConfig/Executable/CMakeLists.txt:97:add_custom_command(TARGET
complex POST_BUILD
./ComplexOneConfig/Executable/CMakeLists.txt:100:add_custom_command(TARGET
complex POST_BUILD
./ComplexOneConfig/Library/CMakeLists.txt:84:add_custom_command(TARGET
CMakeTestLibraryShared POST_BUILD
./ComplexOneConfig/Library/CMakeLists.txt:87:add_custom_command(TARGET
CMakeTestLibraryShared POST_BUILD
./CustomCommand/CMakeLists.txt:119: TARGET TDocument POST_BUILD
./CustomCommand/CMakeLists.txt:204:add_custom_command(TARGET
CustomCommandUsingTargetTest POST_BUILD
./CustomCommand/GeneratorInExtraDir/CMakeLists.txt:7:# add an executable
which will be called from add_custom_command( ... POST_BUILD)
./Jump/Library/Shared/CMakeLists.txt:23:POST_BUILD COMMAND
${CMAKE_COMMAND} ARGS -E copy
./MakeClean/CMakeLists.txt:46: POST_BUILD
./SimpleInstall/CMakeLists.txt:385: POST_BUILD
./SimpleInstallS2/CMakeLists.txt:385: POST_BUILD
./SubDir/Examples/example1/CMakeLists.txt:5:add_custom_command(TARGET
example1 POST_BUILD
./SubDirSpaces/Some
Examples/example1/CMakeLists.txt:5:add_custom_command(TARGET example1
POST_BUILD
[5345] Tests $ find . -name *.cmake -o -name CMakeLists.txt -print0 |
xargs -0 grep -n --color PRE_LINK
On Wed, Dec 12, 2012 at 9:32 AM, Brad King brad.k...@kitware.com wrote:
On 12/12/2012 11:02 AM, James Bigler wrote:
Are there any tests for PRE_BUILD | PRE_LINK | POST_BUILD arguments to
add_custom_command? I did a search in the repository, but I'm not seeing
anything:
$ find . -name *.cmake -o -name CMakeLists.txt -print0 | xargs -0
grep -n --color PRE_BUILD
$ find . -name *.cmake -o -name CMakeLists.txt -print0 | xargs -0
grep -n --color PRE_LINK
$ find . -name *.cmake -o -name CMakeLists.txt -print0 | xargs -0
grep -n --color POST_BUILD
There are mentions of it in the Tests directory:
$ git grep -l -E '(PRE|POST)_BUILD|PRE_LINK' -- Tests |wc -l
22
but I don't know how robustly they are covered.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Tests for PRE_BUILD | PRE_LINK | POST_BUILD
On 12/12/2012 01:09 PM, James Bigler wrote: not PRE_LINK. I'm seeing problems with PRE_LINK not working in VS 2010, so I wanted to see if it was actually being tested. It appears PRE_LINK is not tested. However, the implementation of all three looks the same in one place in the VS10 generator: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmVisualStudio10TargetGenerator.cxx;hb=v2.8.10.2#l1617 -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Tests for PRE_BUILD | PRE_LINK | POST_BUILD
I just noticed something when I wanted to try and add a test. I think the
test might have already been there, but it was broken due to a copy/paste
error:
Tests/Complex/Executable/CMakeLists.txt
# Test pre-build/pre-link/post-build rules for an executable.
add_custom_command(TARGET complex PRE_BUILD
COMMAND ${CREATE_FILE_EXE}
ARGS ${Complex_BINARY_DIR}/Executable/prebuild.txt)
add_custom_command(TARGET complex PRE_LINK
COMMAND ${CREATE_FILE_EXE}
ARGS ${Complex_BINARY_DIR}/Executable/prelink.txt)
add_custom_command(TARGET complex POST_BUILD
COMMAND ${CREATE_FILE_EXE}
ARGS ${Complex_BINARY_DIR}/Executable/postbuild.txt)
add_custom_command(TARGET complex POST_BUILD
COMMAND ${CMAKE_COMMAND}
ARGS -E copy
${Complex_BINARY_DIR}/Executable/postbuild.txt
${Complex_BINARY_DIR}/Executable/postbuild2.txt)
The command to do generate prelink.txt was using PRE_BUILD instead of
PRE_LINK.
If you fix this, what do the dashboards tell you? I'm going to try it
locally as well.
James
On Wed, Dec 12, 2012 at 11:38 AM, Brad King brad.k...@kitware.com wrote:
On 12/12/2012 01:09 PM, James Bigler wrote:
not PRE_LINK. I'm seeing problems with PRE_LINK not working in VS 2010,
so I wanted to see if it was actually being tested.
It appears PRE_LINK is not tested. However, the implementation of all
three looks the same in one place in the VS10 generator:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmVisualStudio10TargetGenerator.cxx;hb=v2.8.10.2#l1617
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Tests for PRE_BUILD | PRE_LINK | POST_BUILD
On 12/12/2012 02:10 PM, James Bigler wrote: I think the test might have already been there, but it was broken due to a copy/paste error: The command to do generate prelink.txt was using PRE_BUILD instead of PRE_LINK. Good catch. From the docs: Note that the PRE_BUILD option is only supported on Visual Studio 7 or later. For all other generators PRE_BUILD will be treated as PRE_LINK. so I guess for non-VS generators it was testing as pre-link anyway ;) If you fix this, what do the dashboards tell you? I'm going to try it locally as well. You have sufficient privileges to merge the fix to 'next' for testing and follow up with dashboard results. I won't have time for a while. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013788]: Hide Automoc Targets in Visual Studio projects
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13788 == Reported By:Shaun Williams Assigned To: == Project:CMake Issue ID: 13788 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2012-12-12 15:07 EST Last Modified: 2012-12-12 15:07 EST == Summary:Hide Automoc Targets in Visual Studio projects Description: This is a feature request to hide the target_automoc projects in a folder in Visual Studio: http://public.kitware.com/pipermail/cmake-developers/2012-June/004402.html It is also related to issue 0013688. The included patch adds in a new global property: $ cmake --help-property AUTOMOC_FOLDER cmake version 2.8.10.20121212 AUTOMOC_FOLDER Name of FOLDER for *_automoc targets that are added automatically by CMake. If not set, CMake uses the FOLDER property of the parent target as a default value for this property. See also the documentation for the FOLDER target property and the AUTOMOC target property. Steps to Reproduce: SET_PROPERTY(GLOBAL PROPERTY USE_FOLDERS ON) SET_PROPERTY(GLOBAL PROPERTY AUTOMOC_FOLDER automoc) == Issue History Date ModifiedUsername FieldChange == 2012-12-12 15:07 Shaun Williams New Issue 2012-12-12 15:07 Shaun Williams File Added: automoc_folder.patch == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] exports and MAP_IMPORTED_CONFIG_CONFIG (was: Policy for INTERFACE_LINK_LIBRARIES)
On 12/09/2012 08:48 AM, Stephen Kelly wrote: I think the 'Setting include directories via target_link_libraries() ?' thread needs to be concluded first (with reasoning), as that affects everything else. While thinking about my next response to that discussion I realized that most of our discussion so far about exported interfaces has missed a major piece. You briefly mentioned it while we discussed the syntax of the $CONFIG_DEBUG expression. It is MAP_IMPORTED_CONFIG_CONFIG: http://www.cmake.org/cmake/help/v2.8.10/cmake.html#prop_tgt:MAP_IMPORTED_CONFIG_CONFIG Every part of an exported interface (link interface libraries, include dirs, compile definitions, etc.) potentially depends on the configuration being exported from the project. The exporting project knows nothing of the importing projects' configurations. All evaluation of its generator expressions must be done using only one of the original configurations for expressions like $CONFIG:..., $CONFIG_DEBUG and $CONFIGURATION. One approach to this is to perform partial evaluation of all exported interfaces to resolve generator expressions that depend on the config. Then store the results in exported properties ending in _CONFIG. This is essentially what CMake = 2.8.10 does to produce properties like IMPORTED_LINK_INTERFACE_LIBRARIES_CONFIG, but that is actually full evaluation because there is no support for generator expressions. The importing project then selects one of the exported configurations using heuristics and MAP_IMPORTED_CONFIG_CONFIG if defined. Another approach is to try to honor the configuration mapping while evaluating exported generator expressions in the importing project. Evaluation would need to track when it crosses into expressions that came from another project and lookup the configuration mapping. Note that the above holds for not only link interface libraries but for any new usage requirements support too. For example in the partial evaluation approach the exported interfaces would need properties like (IMPORTED_)?INCLUDE_DIRECTORIES_CONFIG (IMPORTED_)?COMPILE_DEFINITIONS_CONFIG Such properties are distinct from properties like INCLUDE_DIRECTORIES in that they will not contain config-dependent generator expressions. Comments? -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting include directories via target_link_libraries() ?
On Tuesday 11 December 2012, Stephen Kelly wrote:
Brad King wrote:
On 12/07/2012 06:10 AM, Stephen Kelly wrote:
Stephen Kelly wrote:
I haven't tried to analyse how much of the complexity is due to whether
target_use_targets or target_link_libraries is used. I think the harder
parts of this topic so far have been related to exports.
I've split out the part of the commit that changes tll(), and I think
the complexity remains in the part that would be essential even with a
new command.
Obviously there will be complexity inherent to the new capabilities.
I think the goal of this discussion is to re-design the interface that
enables the new features in order to avoid complexity related to backward
compatibility.
What kind of complexity?
Complexity of implementation, or complexity for users (having to understand
that using tll() with targets means not needing include_directories() after
the patch)?
Alex's concern is the latter only afaik.
Yes, I was looking at this only from a users perspective so far.
I still think that introducing a
new command is more complex for all users.
Here we disagree.
If these are separate commands, both examples below can be valid cmake code
for the same installation of package Foo:
find_package(Foo REQUIRED)
include_directories(${Foo_INCLUDE_DIRS})
add_executable(hello main.cpp)
target_link_libraries(hello ${Foo_LIBRARIES})
-
as well as
find_package(Foo REQUIRED)
add_executable(hello main.cpp)
target_use_targets(hello TARGETS Foo:FooLib)
IMO it is a good thing that this way a package can support both the old and
the new way at the same time, and that using a package the new way is very
obvious from just looking at the cmake code.
A similar effect can be achieved by adding a keyword to tll(), e.g.
target_link_libraries(hello ${JPEG_LIBRARIES} USE_INTERFACES Foo:FooLib)
This would have the same effect, but people could simply hide the
USE_INTERFACES keyword in a variable:
set(Foo_LIBRARIES USE_INTERFACES Foo::FooLib)
and then it's again hidden:
target_link_libraries(hello ${JPEG_LIBRARIES} ${Foo_LIBRARIES})
...
Even if we have a policy for when people use the old and new command
with the same foo, people will use both tll() and the new command in
the same project (with different targets), and that will be confusing
for them.
Why will this be confusing ?
Those two commands will have clear and separate functionality.
tll() links, the new one links, sets include dirs and defines using target
propertiesm and it can error/warn if something else that a target with all
necessary properties is used there.
Another idea is to simply not allow both commands to be used on a given
target.
Yes, that's what I means by policy with the same foo. But I guess as it's a
new command, no policy would be needed.
I do think that proposal makes the whole thing harder to use, and makes the
user need to understand a lot more about what's going on under the hood.
Since the new command does not yet exist this cannot break any
existing projects. One must either specify everything by the new command
or everything by the old command.
We could also use this to switch the default link interface to be empty
for shared library targets. If a newly created target doesn't link to
anything then of course its link interface is empty too. Once one uses
the new command to link to something then since it is a new command we
can make the link interface empty without changing existing projects.
True.
I like Daniel's name target_use_interfaces for the new command rather
than target_use_targets. The RHS might not always be targets.
Alex's proposal was that it would only accept targets, not library paths.
What else do you think would be in the RHS apart from targets?
I don't like the target_use_interfaces name because it conflicts with the
INTERFACE_LIBRARY type. The name implies that it can only be used with
targets of that type.
Anyway, let's discuss the actual name of any new command later.
For now, can we agree that the only reason to use a new command or not
depends on complexity for the user?
Then can someone (preferably not me) please make a list of the types of
users who will be affected by either choice (and in what situations) and we
can discuss that?
Eg, I don't believe most developers of KDE applications will be affected -
in practice they ignore the buildsystem
I prefer obviousness over convenience.
While this may lead to more code, it makes the code easier to understand and
easier to debug, and hopefully less likely to be considered as magic and
thus be ignored. ;-)
and it is Alex or, more likely, me
who will port them to KDE Frameworks 5 on a buildsystem level at least. Any
power users of CMake will learn about any new tll behavior from the release
notes, and non-power users probably won't notice until the notice by
accident. New
[cmake-developers] [CMake 0013789]: WIX additional support for Product Icon, UI Dialog and UI Banner
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13789 == Reported By:Eric LaFranchi Assigned To: == Project:CMake Issue ID: 13789 Category: CMake Reproducibility:always Severity: feature Priority: high Status: new == Date Submitted: 2012-12-12 19:03 EST Last Modified: 2012-12-12 19:03 EST == Summary:WIX additional support for Product Icon, UI Dialog and UI Banner Description: CMake 2.8.11 work in progress branch. The WIX support works fine, no issues. I want to propose a straight forward addition for the 2.8.11 release. 1. Offer the option to set the application icon that appears in Uninstall or change a program (add/remove programs). 2. Offer the option to set the UI Banner and UI Dialog images. Steps to Reproduce: Latest source. Windows XP or later 32/64 bit system. Create a WIX package and then examine the Uninstall or change a program (add/remove programs) and notice the default WIX icon. The installer uses WIX default images for initial UI dialog and the UI banner. Additional Information: I did not update the tests; set the variables is optional and someone will need to manually run the installer to see if they work correctly. New CMake variables: CPACK_WIX_PRODUCT_ICON CPACK_WIX_UI_BANNER CPACK_WIX_UI_DIALOG Documentation: CPACK_WIX_PRODUCT_ICON -- icon used to the left of the application entry in add/remove programs. CPACK_WIX_UI_BANNER -- 493 by 58 pixels, this bitmap will appear at the top of all but the first page of the installer. CPACK_WIX_UI_DIALOG -- 493 by 312 pixels, this bitmap will appear on the first page of the installer. Two files are updated: cmCPackWIXGenerator.cxx and WIX.template.in. Diffs attached. == Issue History Date ModifiedUsername FieldChange == 2012-12-12 19:03 Eric LaFranchi New Issue 2012-12-12 19:03 Eric LaFranchi File Added: CMake-WIX-Feature-Request.diff == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] linking static library.
Does somebody has some ideas? Can I enforce cmake to make library as a one 'shoot' - single command line? thanks in advance Lukasz Łukasz Tasz 2012/12/5 Łukasz Tasz luk...@tasz.eu: Hi all, I have a problem with making static library. There is behaviour which is not clear for me. I have long list of objects to be linked. For shared library linking is done as one g++ command, For static sources are grouped into few groups and there is sequence of: ar cr libnanme obj_list1 ar r libnanme obj_list2 ar r libnanme obj_list3 ... Could somebody explain me what's the reason for such a grouping? Issue at my side is that both objects wont go to the archive if: ar cr foo/foo.o ar r bar/foo.o bar/foo.o will replace foo/foo.o I know it's not a good idea to put same name of object info archive, but it's still valid... I would like to avoid replacing template for appending to static library CMAKE_C_ARCHIVE_APPEND thank in advance Łukasz Tasz -- 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] [vtkusers] Fwd: CMAKE_MAKE_PROGRAM is not set - Win7 and Visual Studio 10
On Wed, Dec 12, 2012 at 4:03 AM, Benoît Thiébault thieba...@artenum.com wrote: Hi everyone, I sent this question on CMake mailing list a week ago and never had any answer. As it deals with compiling VTK, I'm thinking maybe some of you have a solution. Can't you specify the location of the make program in CMake-gui? That is until a better solution is worked out. John -- 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_MAKE_PROGRAM is not set - Win7 and Visual Studio 10
On 05.12.2012 14:21, Benoît Thiébault wrote:
$ENV{ProgramFiles} (x86)/Microsoft Visual Studio 10.0/Common7/IDE
$ENV{ProgramFiles} (x86)/Microsoft Visual Studio10.0/Common7/IDE
$ENV{ProgramFiles} (x86)/Microsoft Visual Studio 10/Common7/IDE
$ENV{ProgramFiles} (x86)/Microsoft Visual Studio10/Common7/IDE
The environment variable is called ProgramFiles(x86)
$ENV{ProgramFiles(x86)}/Microsoft Visual Studio 10.0/Common7/IDE
$ENV{ProgramFiles(x86)}/Microsoft Visual Studio10.0/Common7/IDE
$ENV{ProgramFiles(x86)}/Microsoft Visual Studio 10/Common7/IDE
$ENV{ProgramFiles(x86)}/Microsoft Visual Studio10/Common7/IDE
Looks like a CMake bug to me.
Best regards
Andreas
--
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] [vtkusers] Fwd: CMAKE_MAKE_PROGRAM is not set - Win7 and Visual Studio 10
The question is: what is the location of the make program? If I remember correctly, on Windows XP, I did not have to install MinGW to compile VTK. Just Visual Studio Express was required. Do I have to install MinGW? Not unless you want to move your development to MinGW. Or is it provided by VS? This should be devenv.com or msbuild.exe (located in your system .NET location). However I believe the express version of VisualStudio does not work with MSBuild so make it the location of devenv.com A more general question, what is the recommended way to compile VTK on Windows? I am not sure about recommended however I build vtk from the command line via a Visual Studio command prompt. I first configure VTK to turn off shared libraries because I want to avoid having to copy dlls around. cmake --build PathToBuildFolderForVTK --config Debug cmake --build PathToBuildFolderForVTK --config Release cmake --build PathToBuildFolderForVTK --config RelWithDebInfo After that I do not install VTK. Since the INSTALL will only install a single configuration. I instead point my own projects that use cmake to use the vtk build folder as VTK_DIR and CMake is happy to set it up so that my debug configurations will use debug vtk libs and my release applications will use release vtk libs. John -- 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] CC, CXX ( Fortran) compiler version - CMake macros wanted
On 12/11/2012 04:20 PM, Ilias Miroslav wrote:
I appreciate your efforts resulting into the introduction of
the CMAKE_[C|CXX]_COMPILER_VERSION variables
Thanks.
However, I would need also the CMAKE_Fortran_COMPILER_VERSION variable.
It was not left out by accident. It cannot be computed using the same
approach. The C/C++ compiler version detection works by using the
preprocessor to transform the version macros for each compiler into
string literals encoded in a binary. AFAICT this is not possible with
Fortran. Even though we can preprocess the files, there is no way to
get a compile-time-computed string literal into the binary because the
compiler will not evaluate expressions in static initializers. As a
result all we can do with the preprocessor in Fortran is select from a
list of hand-coded strings for the compiler identification, not version.
A different method, such as trying to run the compiler binary with a
vendor-specific version query flag, will be needed for Fortran. Only
recently was enough infrastructure added to know the full path to the
compiler binary in all generators (including the IDEs) in order to be
able to run it. I don't remember off the top of my head if detection
of the full path to the compiler works for Fortran yet.
For that reason I was searching for macros setting CMAKE_C_COMPILER_VERSION
The line closest to what you are looking for is in the module
Modules/CMakeDetermineCompilerId.cmake in the function
CMAKE_DETERMINE_COMPILER_ID_CHECK:
set(CMAKE_${lang}_COMPILER_VERSION ${COMPILER_VERSION})
However:
Would it be possible to distribute also CMake source files which are
setting the MAKE_[C|CXX]_COMPILER_VERSION variables?
The logic cannot be factored out into separately-distributable modules,
especially not to run with older CMake versions. It is dependent on
a lot of infrastructure added to both Modules/*.cmake and C++ sources.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Inconsistent CMake Warning on policy CMP0012
Hi all, I noticed that, when using a string expression in an IF() statement -- which you obviously shouldn't do, but I was just playing around -- CMake sometimes generates a developer warning CMP0012. Whether it does that or not depends on the string your using. The following file $ cat string_in_conditional.cmake if(x) message(STATUS \x\ evaluate to TRUE) else() message(STATUS \x\ evaluate to FALSE) endif() if(y) message(STATUS \y\ evaluate to TRUE) else() message(STATUS \y\ evaluate to FALSE) endif() produces the following output when run with cmake 2.8.9 $ cmake -P string_in_conditional.cmake -- x evaluate to FALSE CMake Warning (dev) at string_in_conditional.cmake:6 (if): given arguments: y An argument named y appears in a conditional statement. Policy CMP0012 is not set: if() recognizes numbers and boolean constants. Run cmake --help-policy CMP0012 for policy details. Use the cmake_policy command to set the policy and suppress this warning. This warning is for project developers. Use -Wno-dev to suppress it. -- y evaluate to FALSE I.e., it doesn't produce a warning when using x in an if() statement, but it does when using y. Best regards, Marcel Loose. attachment: loose.vcf-- 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] FindThreads: GCC pthreads bug?
Hi all, I was browsing the FindThreads.cmake code and was wondering whether it is doing the right thing when using GCC and pthreads. The thing is that it first tries to locate the threads library and only if it *cannot* find it, tries the command-line option -pthread. The proper way to tell GCC to compile with thread support is to use the -pthread command-line option. Besides instructing the linke to link against -lpthread, it will also set some preprocessor variables, like _REENTRANT. Hence, simply linking against -lpthread is not sufficient. So, IMHO, the test for the command-line option -pthread should be tried first; and FindThreads should also set a variable containing the preprocessor variables that should be set using add_definitions(). And a bit off topic: shouldn't FindThreads.cmake adhere to the convention of setting a cache variable THREADS_LIBRARY and a non-cache variable THREADS_LIBRARIES? Best regards, Marcel Loose. attachment: loose.vcf-- 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] Inconsistent CMake Warning on policy CMP0012
Only the special strings cause the warning. Things like Y y N n true 0 1 on off etc. This is correct behavior and what the policy is about. It's not about strings in general, but about the specific strings that are used for boolean constant aliases... On Wed, Dec 12, 2012 at 10:30 AM, Marcel Loose lo...@astron.nl wrote: Hi all, I noticed that, when using a string expression in an IF() statement -- which you obviously shouldn't do, but I was just playing around -- CMake sometimes generates a developer warning CMP0012. Whether it does that or not depends on the string your using. The following file $ cat string_in_conditional.cmake if(x) message(STATUS \x\ evaluate to TRUE) else() message(STATUS \x\ evaluate to FALSE) endif() if(y) message(STATUS \y\ evaluate to TRUE) else() message(STATUS \y\ evaluate to FALSE) endif() produces the following output when run with cmake 2.8.9 $ cmake -P string_in_conditional.cmake -- x evaluate to FALSE CMake Warning (dev) at string_in_conditional.cmake:6 (if): given arguments: y An argument named y appears in a conditional statement. Policy CMP0012 is not set: if() recognizes numbers and boolean constants. Run cmake --help-policy CMP0012 for policy details. Use the cmake_policy command to set the policy and suppress this warning. This warning is for project developers. Use -Wno-dev to suppress it. -- y evaluate to FALSE I.e., it doesn't produce a warning when using x in an if() statement, but it does when using y. Best regards, Marcel Loose. -- 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 -- 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)
+
Re: [CMake] Testing Qt 5 RC 1 CMake files
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. I will see what I can do this weekend. Thanks, John -- 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
Doesn't seem like return false; is quite the right implementation for vtkQtView::SaveImage... ;-) On Wed, Dec 12, 2012 at 12:41 PM, John Drescher dresche...@gmail.comwrote: 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. I will see what I can do this weekend. Thanks, John -- 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 -- 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
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)
+ if
[CMake] Why is XXX_INCLUDE_DIRS plural and should it be deep?
Hi all, I am trying to adapt an existing FindNetCDF.cmake file to work with NetCDF 4.2. I have read the Modules/Readme.txt but I am still a little unclear to the best approach in my case. In 4.2 the Fortran bindings and C bindings are not necessarily installed in the same place. One motive for NetCDF_INCLUDE_DIRS to be plural is that there might be a NetCDF_C_INCLUDE_DIR and a NetCDF_Fortran_INCLUDE_DIR that together form NetCDF_INCLUDE_DIRS. There is a second motive that I am less clear on. The FindNetCDF.cmake files I have seen handle the HDF5 dependency differently: 1. One sets a variable NETCDF_HAS_HDF5 by querying a config executable but does nothing else. 2. The other sets a similar variable but then does find_package on HDF5 and loads the dependencies into NetCDF_INCLUDE_DIRS and NetCDF_LIBRARIES. This design (2) cascades. FindHDF5.cmake represents a similar decision about whether to find_package its dependencies like the zlib compression library. I believe the one in the cmake distro doesn't do that. What is the best practice here? To handle dual locations for the library at hand or to accumulate or both? The first seems unavoidable ... the second seems to be an unevenly applied standard. Thanks Eli -- View this message in context: http://cmake.3232098.n2.nabble.com/Why-is-XXX-INCLUDE-DIRS-plural-and-should-it-be-deep-tp7582623.html Sent from the CMake mailing list archive at Nabble.com. -- 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] Why is XXX_INCLUDE_DIRS plural and should it be deep?
esatel wrote: 2. The other sets a similar variable but then does find_package on HDF5 and loads the dependencies into NetCDF_INCLUDE_DIRS and NetCDF_LIBRARIES. This design (2) cascades. FindHDF5.cmake represents a similar decision about whether to find_package its dependencies like the zlib compression library. I believe the one in the cmake distro doesn't do that. What is the best practice here? To handle dual locations for the library at hand or to accumulate or both? The first seems unavoidable ... the second seems to be an unevenly applied standard. My personal vote on this is: if the public headers of package X include headers from one of it's dependencies then you should cascade. So if netcdf.h does #ifdef WITH_HDF5 #include hdf5.h #endif then you would get a compile error if the HDF5 include directories are not set. If this is just an internal dependency or you would explicitely need to include e.g. netcdf/hdf5.h to get that sort of stuff then I would vote for not becoming recursive. Which is a sane default as most packages will not need that recursive approach then. Eike -- 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] can I install subdirs matching a REGEX ?
Hi Martin, if you only want to install files which match something, you need to add FILES_MATCHING to the insall() command (before the first pattern/regex), like this: install(DIRECTORY start/ DESTINATION images FILES_MATCHING REGEX .*/\\.Images/.*) (I've also added backslashes, since you probably want to match a literal period in .Images) Petr On Tue, Dec 11, 2012 at 8:47 AM, Martin Koller martin.kol...@etm.at wrote: I have a directory tree, which contains a lot subtrees in different levels, all starting with .Images e.g. start/def/file1 start/def/.Images/hello start/xyz/blaa/.Images/something There are a lot .Images subdirs and they are actually extracted from a tar file. What I want is to install all those subtrees starting with .Images to a destination. I tried with REGEX and PATTERN, e.g.: install(DIRECTORY start/ DESTINATION images REGEX .*/.Images/.*) but it does not work as it installs everything below start. Can I match ONLY DIRECTORY names which will then be used to install everything below it ? -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments This mail was not scanned before sending. It was sent from a secure Linux desktop. -- 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 -- 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-commits] CMake branch, master, updated. v2.8.10.2-314-gf6a9a64
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via f6a9a64f16a6f79095dd3eb9563999253fa18f9f (commit) from daf17b13d5c8694c43c3c127dedbc93a1b2a894b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f6a9a64f16a6f79095dd3eb9563999253fa18f9f commit f6a9a64f16a6f79095dd3eb9563999253fa18f9f Author: Kitware Robot kwro...@kitware.com AuthorDate: Thu Dec 13 00:01:03 2012 -0500 Commit: Kitware Robot kwro...@kitware.com CommitDate: Thu Dec 13 00:01:03 2012 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 41fc6a2..59bac2d 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 10) -set(CMake_VERSION_TWEAK 20121212) +set(CMake_VERSION_TWEAK 20121213) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
