Re: [cmake-developers] FindBoost.cmake cannot find some libraries when cross-compiling
Please find the patch attached to this email.
Let me know if anything is wrong.
Best,
Guillaume
On 10/16/2014 05:09 PM, Chuck Atkins wrote:
Guillaume,
Please see CONTRIBUTING.rst in the top level of the CMake source
tree. If you can please create and post a patch against cmake master
then I'll work on getting it merged into cmake next. Thanks for the
bug fix!
- Chuck
On Thu, Oct 16, 2014 at 10:32 AM, Chuck Atkins
chuck.atk...@kitware.com mailto:chuck.atk...@kitware.com wrote:
This looks like a reasonable way to accomplish this right now.
The underlying prioblem is that ther's no way to specify which
path types get re-rooted and which don't. Ideally you'd want to
be able to specify in the toolchain for something like this that
all paths operate in ONLY mode except HINTS, which you would
want to place in NEVER mode. I'm currently working on just such a
feature but in the meantime, forcing it like this in the FindBoost
module looks reasonable.
From 136f1362f466e5ed54e5d1b969f08d37c03d7be4 Mon Sep 17 00:00:00 2001
From: Guillaume Papin guillaume.pa...@parrot.com
Date: Thu, 23 Oct 2014 09:10:54 +0200
Subject: [PATCH] FindBoost: fix find_library call when using re-rooting
When using CMAKE_FIND_ROOT_PATH, FindBoost was able to find the first
component and cache the full-path of the directory in Boost_LIBRARY_DIR
so that all components were looked in same directory. The issue was
that, when looking for the other components, Boost_LIBRARY_DIR was
re-rooted against CMAKE_FIND_ROOT_PATH even though it was already a path
on the host. This change fix this by disabling the re-rooting in the
find_library call when using Boost_LIBRARY_DIR as a hint.
See http://www.cmake.org/pipermail/cmake-developers/2014-October/011670.html
---
Modules/FindBoost.cmake | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 3642b3e..aad6575 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -321,7 +321,7 @@ macro(_Boost_FIND_LIBRARY var)
# If Boost_LIBRARY_DIR is known then search only there.
if(Boost_LIBRARY_DIR)
-set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH)
+set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
endif()
endmacro()
@@ -855,7 +855,7 @@ if(_Boost_CHANGE_LIBDIR AND NOT _Boost_LIBRARY_DIR_CHANGED)
endif()
if(Boost_LIBRARY_DIR)
- set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH)
+ set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
else()
set(_boost_LIBRARY_SEARCH_DIRS )
if(BOOST_LIBRARYDIR)
--
1.9.1
--
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://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [TEST REQUEST] CPack IFW generator on OSX
Hello developers! Can anybody test IFW generator on Mac? Regards, Konstantin Podsvirov -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [TEST REQUEST] CPack IFW generator on OSX
On Thu, 23 Oct 2014 16:45:36 +0400, Konstantin Podsvirov said: Can anybody test IFW generator on Mac? Probably... What is it? :) How would I test it? If you can give me clear instructions, I can update one or more of my dashboards to test it. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Support of codesign
On 10/21/2014 11:44 AM, Clinton Stimpson wrote: Because the design of this Bundle generator is not consistent with the rest of the CPack generators, you don't have this same chance, and the only way to do customization is to keep adding patches like yours. Is this something that should be refactored in CPack to address independently of the codesign changes? Thanks, -Brad -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [TEST REQUEST] CPack IFW generator on OSX
Hi Sean!
23.10.2014, 19:09, Sean McBride s...@rogue-research.com:
On Thu, 23 Oct 2014 16:45:36 +0400, Konstantin Podsvirov said:
Can anybody test IFW generator on Mac?
Probably... What is it? :) How would I test it? If you can give me clear
instructions, I can update one or more of my dashboards to test it.
Thanks that have responded.
CPack IFW generator generates the installer with a graphical user interface.
I have no ideas for automated testing. But you can try to create the installer
and see how it works.
On the CMake Wiki has an article CMake:Install Component With CPack:
http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack
CPack IFW generator will cope with this task.
Shot with a small edit to IFW generator available here:
http://git.podsvirov.pro/?p=kitware/componentexample.git;a=snapshot;h=refs/heads/develop;sf=tgz
You must use the latest version of CMake for developers.
You can find here:
http://www.cmake.org/files/dev
Just need to install Qt Installer Framework from here:
http://download.qt-project.org/official_releases/qt-installer-framework/1.5.0
Then initialize the project from the snapshot.
Further configuration.
Must be set to ON (enble) advanced variable CPACK_BINARY_IFW.
Also must be set to OFF (disable) the rest CPACK_BINARY_{XXX} variables.
Start the generation.
Make the target package and get the installer in the folder Assembly.
Run the installer. We should see the installer similar to what is specified in
the Wiki.
For Linux and Windows I got these installers:
http://ifw.podsvirov.pro/cmake/old/cpackifw-componentexample-linux.png
http://ifw.podsvirov.pro/cmake/old/cpackifw-componentexample-windows.png
Then click next and check that mylibapp start.
Here is an approximate algorithm.
Regards,
Konstantin Podsvirov
--
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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Support of codesign
On Thursday, October 23, 2014 11:13:15 AM Brad King wrote:
On 10/21/2014 11:44 AM, Clinton Stimpson wrote:
Because the design of this Bundle generator is not consistent with the
rest of the CPack generators, you don't have this same chance, and the
only way to do customization is to keep adding patches like yours.
Is this something that should be refactored in CPack to address
independently of the codesign changes?
Actually, the design is intentional -- that is, it has the feature of creating
the application bundle for you, which involves handling for icons, Info.plist,
and now the proposed code signing. Alternatively, we have handling for icons
and Info.plist in add_executable(... MACOSX_BUNDLE ...). So basically, its
duplicated functionality.
There are 2 approaches:
1.
set(INSTALL_LIB_DIR lib)
set(INSTALL_BIN_DIR bin)
add_library(foolib ...)
install(TARGETS foolib RUNTIME DESTINATION ${INSTALL_LIB_DIR})
add_executable(foo ...)
target_link_libraries(foo foolib)
add_executable(foo2 ...)
target_link_libraries(foo2 foolib)
install(TARGETS foo foo2 RUNTIME DESTINATION ${INSTALL_BIN_DIR})
set(CPACK_GENERATOR Bundle)
set(CPACK_BUNDLE_STARTUP_COMMAND StartScript)
include(CPack)
The end result is a
foo.app/Contents/MacOS/foo (renamed from StartScript)
foo.app/Contents/MacOS/bin/foo
foo.app/Contents/MacOS/bin/foo2
foo.app/Contents/MacOS/lib/libfoo.dylib
If any other CPack generator is used (TGZ, DragNDrop, PackageMaker, etc...),
the package layout will be
bin/foo
bin/foo2
lib/libfoo.dylib
2.
set(INSTALL_LIB_DIR foo.app/Contents/MacOS)
set(INSTALL_BIN_DIR foo.app/Contents/MacOS)
add_library(foolib ...)
install(TARGETS foolib RUNTIME DESTINATION ${INSTALL_LIB_DIR})
add_executable(foo MACOSX_BUNDLE ...)
target_link_libraries(foo foolib)
add_executable(foo2 MACOSX_BUNDLE ...)
target_link_libraries(foo2 foolib)
install(TARGETS foo foo2 BUNDLE DESTINATION .
RUNTIME DESTINATION ${INSTALL_BIN_DIR})
include(CPack)
The end result is a
foo.app/Contents/MacOS/foo
foo.app/Contents/MacOS/foo2
foo.app/Contents/MacOS/libfoo.dylib
This gives consistent results with all CPack generators (TGZ, DragNDrop,
PackageMaker, etc..) except for the Bundle generator.
Similar to #2, CMake itself uses an interesting approach of modifying
CMAKE_INSTALL_PREFIX to redirect the installation into the CMake.app bundle,
without modifying the DESTINATION option to the install() commands.
If the Bundle generator is changed to be made consistent with other cpack
generators (which implies you lose the bundle making feature), you end up with
what the DragNDrop generator is.
And now there is code signing There is a chance that code signing will be
introduced into CMake using another mechanism that works across platforms and
across cpack generators. How that will interact with the propose patch, I do
not know, so I do have some concern about adding this patch.
So Brad, does this give you some idea of the situation? Do you have some
thoughts on merging the patch?
Clint
--
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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Support of codesign
Let me put my 2¢. I have feeling that we are mixing up signing (install) packages, such as .pkg (OSX) or .msi (Windows), with signing bundles .app or whatever OSX binaries (that can keep signature inside macho). I think that CPack should be responsible of signing only what it creates. Since CPack does not create .app bundle but just packs it into .pkg, .dmg or whatever else it shouldn't touch .app. Then code signing .app bundle should be part of install (cmake_install.cmake), triggered once the .app bundle is complete (final), probably after fixup_bundle. Once may not even want to use CPack, but still want to code-sign .app when installing. But this is just my personal opinion, Also I don't see any reason we need to implement that in C++ as this can be handled with cmake scripting capabilities. --Adam -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Support of codesign
On 10/23/2014 12:21 PM, Clinton Stimpson wrote: Actually, the design is intentional -- that is, it has the feature of creating the application bundle for you, which involves handling for icons, Info.plist, and now the proposed code signing. Alternatively, we have handling for icons and Info.plist in add_executable(... MACOSX_BUNDLE ...). So basically, its duplicated functionality. Okay, so IIUC the CPack Bundle generator helps create .app bundles out of projects that are not aware of them. Projects that are aware and that use MACOSX_BUNDLE should probably not use the CPack Bundle generator and instead use the DragNDrop generator. If the Bundle generator is changed to be made consistent with other cpack generators (which implies you lose the bundle making feature), you end up with what the DragNDrop generator is. Okay, so it does not make sense to change it. And now there is code signing There is a chance that code signing will be introduced into CMake using another mechanism that works across platforms and across cpack generators. How that will interact with the propose patch, I do not know, so I do have some concern about adding this patch. [snip] On 10/23/2014 01:01 PM, Adam Strzelecki wrote: I think that CPack should be responsible of signing only what it creates. Since CPack does not create .app bundle ... it shouldn't touch .app. Then code signing .app bundle should be part of install (cmake_install.cmake) I think Adam's suggestion makes sense. However, in the case of the Bundle generator that the proposed patch modifies CPack *is* creating the .app bundle and so should be able to sign it. Therefore the patch will not get in the way of future CMake support for signing .app during installation, especially because it requires both explicit configuration and use of the CPack Bundle generator that according to the above recommendation should not be used for projects aware of MACOSX_BUNDLE. In order to keep it further out of the way, the related variables should be specific to the Bundle generator. Instead of: CPACK_APPLE_CERT_APP CPACK_APPLE_ENTITLEMENTS CPACK_APPLE_CODESIGN_FILES perhaps they should be called: CPACK_BUNDLE_APPLE_CERT_APP CPACK_BUNDLE_APPLE_ENTITLEMENTS CPACK_BUNDLE_APPLE_CODESIGN_FILES Thanks, -Brad -- 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://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Fwd: Re: Severe behavioural change regressions in release branch
FYI, a conversation on the KDE mailing list. Forwarded Message Subject: Re: Severe behavioural change regressions in release branch Date: Fri, 24 Oct 2014 10:11:02 +1300 From: Ben Cooksley bcooks...@kde.org Reply-To: KDE build system (cmake) kde-buildsys...@kde.org To: kde-frameworks-de...@kde.org kde-frameworks-de...@kde.org CC: kde-core-devel kde-core-de...@kde.org, KDE build system (cmake) kde-buildsys...@kde.org On Fri, Oct 24, 2014 at 10:05 AM, Ben Cooksley bcooks...@kde.org wrote: Hi all, It would appear that CMake 3.0 to 3.1 introduces a colossal change in behaviour. This change totally breaks all KDE projects which use Extra-CMake-Modules, as necessary headers are no longer installed. This has become an issue following http://build.kde.org/job/cmake/160/ which has led to a significant number of our projects failing to build from source as can be seen here - http://build.kde.org/view/Frameworks/ Someone needs to investigate this before CMake 3.1.0 goes out the door and fix it. I've no idea what the policy is in the CMake world, but in the KDE world this sort of compatibility breakage would be a release blocker. And it would seem that the CMake developers prefer to live in their own closed off little bubble. My post was automatically rejected. Someone who is subscribed there will have to take this up with them. I'm extremely displeased. If they release CMake 3.1.0 with this regression, we should consider forking CMake as their developers can't be trusted to ensure our code remains buildable. Regards, Ben Cooksley KDE Sysadmin Regards, Ben ___ Kde-buildsystem mailing list kde-buildsys...@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Fwd: Re: Severe behavioural change regressions in release branch
[ Adding Ben Cooksley to the CC list; feel free to reply privately and I'll forward to the list if you keep getting rejected from it. ] Hi, It would appear that CMake 3.0 to 3.1 introduces a colossal change in behaviour. This change totally breaks all KDE projects which use Extra-CMake-Modules, as necessary headers are no longer installed. This is indeed true (between the new variable expansion code (CMP0053) and 'if()' variable expansion rules (CMP0054), there's a lot of changes otherwise); however, all you should get are warnings about the change, not the actual behavior change without actually bumping your minimum version or enabling the policy explicitly. This has become an issue following http://build.kde.org/job/cmake/160/ which has led to a significant number of our projects failing to build from source as can be seen here - http://build.kde.org/view/Frameworks/ So looking at kdelibs4support, I see lots of CMP0053 warnings (due to the @var@ expansion in normal CMakeLists.txt processing which was obscure and undocumented) and CMP0048 warnings (I'm not familiar with it, but it's about project() offering version variables). In kdelibs, I see CMP0022 and CMP0046 warnings (both related to target_link_libraries and things which are likely bugs anyways such as depending on non-existent targets or a mismatch between INTERFACE_LINK_LIBRARIES and LINK_INTERFACE_LIBRARIES). However, I do see: 04:35:39 -- Installing: /srv/jenkins/workspace/kdelibs_master/local-inst/srv/jenkins/install/linux/x86_64/g++/latest-qt4/kde/kdelibs/inst/include/kpluginfactory.h in kdelibs' logs, so it makes me think that: /srv/jenkins/workspace/kdelibs4support_master_qt5/src/kssl/kcm/kcmssl.cpp:27:28: fatal error: kpluginfactory.h: No such file or directory implies the build isn't getting the include directories plumbed through properly. I'll try a build tomorrow (or if it'd be possible to run a Jenkins build of kdelibs4support with make VERBOSE=1, that'd be great too since the environment would be consistent then). My gut feeling is some CMP0054 corner case isn't caught and falls through to the new behavior without a warning (or the old behavior was subtly changed in the process), but that's just a shot in the dark. Someone needs to investigate this before CMake 3.1.0 goes out the door and fix it. I've no idea what the policy is in the CMake world, but in the KDE world this sort of compatibility breakage would be a release blocker. Thanks for testing the rc; it should be a blocker on our side too. It would indeed be bad for 3.1.0 to release with such breaking changes. We try really hard for backwards compatibility. Obviously our test coverage is lacking somewhere. And it would seem that the CMake developers prefer to live in their own closed off little bubble. My post was automatically rejected. Someone who is subscribed there will have to take this up with them. I'm extremely displeased. If they release CMake 3.1.0 with this regression, we should consider forking CMake as their developers can't be trusted to ensure our code remains buildable. For preventing this in the future, would it be possible to set up Jenkins build to submit builds for kdelibs and a few other libraries which would test CMake master and submit to CMake's dashboard some results nightly so we can catch these problems more quickly? There are examples in: https://github.com/Kitware/CMake/tree/master/Tests/Contracts for how this is done for other projects already. The instance would then just to set something like CMAKE_CONTRACT_PROJECTS=kdelibs and run CMake's test suite and submit to the dashboard. Thanks, --Ben -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] [CPACK] [RPM] Support of %preun and %postun
2014-10-23 1:57 GMT+02:00 Luc J. Bourhis luc_j_bour...@mac.com: Am I missing something or there is no equivalent of CPACK_RPM_PRE_INSTALL_SCRIPT_FILE to specify %preun or %postun? The variables are missing in documentation but they exist. For %preun you can set CPACK_RPM_PRE_UNINSTALL_READ_FILE or CPACK_RPM_component_PRE_UNINSTALL_SCRIPT_FILE for component packaging. For %postun you can set CPACK_RPM_POST_UNINSTALL_READ_FILE or CPACK_RPM_component_POST_UNINSTALL_SCRIPT_FILE for component packaging. Regards, Domen -- 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://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Is this the proper way to define a package config?
Hi,
Assuming you are not a boost developer / your changes won't be upstreamed,
then creating a BoostConfig.cmake file won't do you much good. If someone wants
to use your project, he/she will have to patch the locally installed boost
version to include a BoostConfig.cmake file.
You might want to have a look into the FindBoost[1] module of cmake.
XXXConfig.cmake files are intended to be written by the creator of a package,
FindXXX.cmake packages are intended as a workaround when a package does not
contain an XXXConfig.cmake file and are usually written by a consumer of a
package.
HTH,
Johannes
[1] http://www.cmake.org/cmake/help/v3.0/module/FindBoost.html
On Friday 17 October 2014 00:18:34 Robert Dailey wrote:
I have a local package of boost built on Windows. It is always
relative to the root of my project at a consistent structure and
location. I wanted to define an import target for this and thought it
might be best to define a BoostConfig.cmake package config file at the
root of the boost lib directory. Is this the right approach? The code
is below.
Note that I do not have this working just yet because I don't know how
to properly setup the interface link libraries. Could use some
guidance here too... thanks.
add_library( Boost STATIC IMPORTED GLOBAL )
file( GLOB boost_debug_libs ${CMAKE_CURRENT_LIST_DIR}/lib/win32/debug/*.lib
) file( GLOB boost_release_libs
${CMAKE_CURRENT_LIST_DIR}/lib/win32/release/*.lib )
set_target_properties( Boost PROPERTIES
IMPORTED_LOCATION_DEBUG lib/win32/debug
IMPORTED_LOCATION_RELEASE lib/win32/release
INTERFACE_INCLUDE_DIRECTORIES include
INTERFACE_LINK_LIBRARIES
$$CONFIG:Debug:${boost_debug_libs}
$$CONFIG:Release:${boost_release_libs}
)
set( Boost_INCLUDE_DIRS include )
set( Boost_LIBRARIES Boost )
--
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://public.kitware.com/mailman/listinfo/cmake
[CMake] Definiting output extension for cross-compilation
Hi, How to tell CMake to use '.o' output object file (instead of the Windows' .obj forced alternative) when cross-compiling ? SET (CMAKE_SYSTEM_NAME Generic) ... SET (CMAKE_C_OUTPUT_EXTENSION .o) has no effect from a project file. forcing SET (UNIX 1) does work, but this is a terrible workaround Thanks, Manu -- 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://public.kitware.com/mailman/listinfo/cmake
[CMake] Concatenating lists back to string
Hi,
I am trying to convert string to list and back with string(REPLACE) and it
doesn't work as expected (tested with cmake 2.8.12 on Ubuntu 14.04 and main
branch in git on Ubuntu 14.10).
cmake_minimum_required( VERSION 2.8.12 )
project(test_list)
set(str_1 abc.def.ghi)
message(str_1: ${str_1})
string(REPLACE . ; list_1 ${str_1})
message(list_1: ${list_1})
string(REPLACE ; . str_2 ${list_1})
message(str_2: ${str_2})
When I run cmake I get the following output:
str_1: abc.def.ghi
list_1: abc;def;ghi
str_2: abcdefghi
what I expected was that str_2 would be the same as str_1.
In case that semicolons are not used everything works as expected:
cmake_minimum_required( VERSION 2.8.12 )
project(test_list)
set(str_1 abc.def.ghi)
message(str_1: ${str_1})
string(REPLACE . ' list_1 ${str_1})
message(list_1: ${list_1})
string(REPLACE ' . str_2 ${list_1})
message(str_2: ${str_2})
Output:
str_1: abc.def.ghi
list_1: abc'def'ghi
str_2: abc.def.ghi
Is this a bug or is there a reason that ; is treated differently since it
represents lists?
Is there any other simpler option than to run foreach on the list and
convert it back to a string?
Thanks,
Domen
--
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://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Concatenating lists back to string
Hi Domen.
This is what helps me reason about it:
A string with a ';' in it is a list.
An unqouted ';' separates arguments to CMake commands.
string(REPLACE ...) simply concatenates all of its 'input' parameters.
So, when you expand ${list_1} in the last line, it will simply replace in
the concatenation of its elements - so there's no semicolon in them, of
course. What you want to do is treat the entire list_1 as a single string:
string(REPLACE ; . str_2 ${list_1})
This should do what you expect.
Petr
On Thu, Oct 23, 2014 at 3:49 PM, Domen Vrankar domen.vran...@gmail.com
wrote:
Hi,
I am trying to convert string to list and back with string(REPLACE) and it
doesn't work as expected (tested with cmake 2.8.12 on Ubuntu 14.04 and main
branch in git on Ubuntu 14.10).
cmake_minimum_required( VERSION 2.8.12 )
project(test_list)
set(str_1 abc.def.ghi)
message(str_1: ${str_1})
string(REPLACE . ; list_1 ${str_1})
message(list_1: ${list_1})
string(REPLACE ; . str_2 ${list_1})
message(str_2: ${str_2})
When I run cmake I get the following output:
str_1: abc.def.ghi
list_1: abc;def;ghi
str_2: abcdefghi
what I expected was that str_2 would be the same as str_1.
In case that semicolons are not used everything works as expected:
cmake_minimum_required( VERSION 2.8.12 )
project(test_list)
set(str_1 abc.def.ghi)
message(str_1: ${str_1})
string(REPLACE . ' list_1 ${str_1})
message(list_1: ${list_1})
string(REPLACE ' . str_2 ${list_1})
message(str_2: ${str_2})
Output:
str_1: abc.def.ghi
list_1: abc'def'ghi
str_2: abc.def.ghi
Is this a bug or is there a reason that ; is treated differently since it
represents lists?
Is there any other simpler option than to run foreach on the list and
convert it back to a string?
Thanks,
Domen
--
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://public.kitware.com/mailman/listinfo/cmake
--
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://public.kitware.com/mailman/listinfo/cmake
[CMake] Controlling the verbosity in CTest scripts
Hi, I am running a CTest script in our continuous and nighty integration builds and tests scheduled by Jenkins. The test suit contains more than 1000 tests with a lot of output. Jenkins has a nice way to digest the test output and present it. What I would like to have is also the output of the build with the warnings and errors. If I launch the script with ctest -VV would do the trick, but it will also print the output of every test. Is there a way to be very verbose for the building and less verbose for the testing? Many thanks in advance, Pere -- 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://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Is this the proper way to define a package config?
Thanks for the reply!
Basically the boost library I have is precompiled and in my own unique
structure. I do not plan to distribute the CMake scripts I write, they
are for personal / internal usage only.
You suggested a find module, but will this also generate a custom
target for boost? That's important so that when I do
target_link_libraries(), I can pass in boost and everything is
handled for me. I do not want to be working with libs header files
directly in each executable or library I define that has a dependency
on boost.
Thanks again.
On Thu, Oct 23, 2014 at 4:59 AM, Johannes Zarl johannes.z...@jku.at wrote:
Hi,
Assuming you are not a boost developer / your changes won't be upstreamed,
then creating a BoostConfig.cmake file won't do you much good. If someone
wants
to use your project, he/she will have to patch the locally installed boost
version to include a BoostConfig.cmake file.
You might want to have a look into the FindBoost[1] module of cmake.
XXXConfig.cmake files are intended to be written by the creator of a package,
FindXXX.cmake packages are intended as a workaround when a package does not
contain an XXXConfig.cmake file and are usually written by a consumer of a
package.
HTH,
Johannes
[1] http://www.cmake.org/cmake/help/v3.0/module/FindBoost.html
On Friday 17 October 2014 00:18:34 Robert Dailey wrote:
I have a local package of boost built on Windows. It is always
relative to the root of my project at a consistent structure and
location. I wanted to define an import target for this and thought it
might be best to define a BoostConfig.cmake package config file at the
root of the boost lib directory. Is this the right approach? The code
is below.
Note that I do not have this working just yet because I don't know how
to properly setup the interface link libraries. Could use some
guidance here too... thanks.
add_library( Boost STATIC IMPORTED GLOBAL )
file( GLOB boost_debug_libs ${CMAKE_CURRENT_LIST_DIR}/lib/win32/debug/*.lib
) file( GLOB boost_release_libs
${CMAKE_CURRENT_LIST_DIR}/lib/win32/release/*.lib )
set_target_properties( Boost PROPERTIES
IMPORTED_LOCATION_DEBUG lib/win32/debug
IMPORTED_LOCATION_RELEASE lib/win32/release
INTERFACE_INCLUDE_DIRECTORIES include
INTERFACE_LINK_LIBRARIES
$$CONFIG:Debug:${boost_debug_libs}
$$CONFIG:Release:${boost_release_libs}
)
set( Boost_INCLUDE_DIRS include )
set( Boost_LIBRARIES Boost )
--
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://public.kitware.com/mailman/listinfo/cmake
--
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://public.kitware.com/mailman/listinfo/cmake
[CMake] Can't build using NINJA with ITKDCMTK/ITKIODCMTK turned on.
A couple of years ago, with massive help from Brad King, I managed to get an embedded ExternalProject build of DCMTK embedded into ITK/Modules/ThirdParty. This was workable, because the CMake dependencies were explicitly set up such that the DCMTK libraries depended on the ExternalProject DCMTK target, and the DCMTKImageIO module depended on the libraries. When using the CMake with the Makefile generator, this hangs together, because the sub-make in Modules/IO/DCMTK won’t happen until the ExternalProject build in Modules/ThirdParty/DCMTK is complete. Ninja, on the other hand, makes one flat megamake at the top level of ITK, and if you try and build with Module_ITKDCMTK/Module_ITKIODCMTK/Module_IOTransformDCMTK turned on, it fails immediately because the targets in Modules/IO/DCMTK depend on non-existent DCMTK libraries. It’s a problem if we support all CMake generators except Ninja. I like using Ninja because it shaves several seconds off build times, which is great when you’re in an edit/compile/test workflow. I have no idea how this could be resolved, except to remove the internal DCMTK build and require USE_SYSTEM_DCMTK=ON. Does anyone have a better idea. Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. -- 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://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [ITK-dev] Can't build using NINJA with ITKDCMTK/ITKIODCMTK turned on.
On 10/23/2014 1:32 PM, Williams, Norman K wrote: I have no idea how this could be resolved, except to remove the internal DCMTK build and require USE_SYSTEM_DCMTK=ON. Does anyone have a better idea. The other option is to build this without external project and use add_subdirectory like we do with other 3rd party stuff (png, etc). Using ExternalProject does not work unless you build everything with external project as this case shows. How hard would that be to do? -Bill -- 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://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [ITK-dev] Can't build using NINJA with ITKDCMTK/ITKIODCMTK turned on.
On 10/23/2014 01:32 PM, Williams, Norman K wrote: it fails immediately because the targets in Modules/IO/DCMTK depend on non-existent DCMTK libraries. This cannot be solved cleanly without addressing these issues: https://github.com/martine/ninja/issues/760#issuecomment-46540858 http://www.cmake.org/Bug/view.php?id=14963#c36130 Currently the only way to build an ExternalProject cleanly with Ninja is if the outer project contains nothing except custom commands/targets, i.e. a superbuild that does both DCMTK and ITK as external projects. -Brad -- 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://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [ITK-dev] Can't build using NINJA with ITKDCMTK/ITKIODCMTK turned on.
Yeah that¹s the problem right there. I would have no problem with including DCMTK in the distro. On 10/23/14, 1:03 PM, Brad King brad.k...@kitware.com wrote: On 10/23/2014 01:32 PM, Williams, Norman K wrote: it fails immediately because the targets in Modules/IO/DCMTK depend on non-existent DCMTK libraries. This cannot be solved cleanly without addressing these issues: https://github.com/martine/ninja/issues/760#issuecomment-46540858 http://www.cmake.org/Bug/view.php?id=14963#c36130 Currently the only way to build an ExternalProject cleanly with Ninja is if the outer project contains nothing except custom commands/targets, i.e. a superbuild that does both DCMTK and ITK as external projects. -Brad Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. -- 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://public.kitware.com/mailman/listinfo/cmake
[CMake] Pass on Unix Signals (ctrl+c)?
I have a number of tests configured in my CMakeLists.txt file, a few of which need to do some cleanup after running or if they are interrupted If I run make tests, and then send a signal (via ctrl+c, for example), however, these signals are not passed on to the test. Is it possible to configure CMake to pass signals on to the tests that are run? Cheers! -- 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://public.kitware.com/mailman/listinfo/cmake
[CMake] CMake, Xcode, and Intel Fortran?
In the past I was able to generate Xcode projects that contained Fortran files via `cmake -gXcode ..` and CMake would pick up the Intel Fortran compiler. This behavior seems to have changed recently, however. Has anyone else experienced this problem and/or found a workaround? Is this is an issue with CMake, Xcode, or the Intel suite? Cheers! -- 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://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Pass on Unix Signals (ctrl+c)?
Alternatively, what signal does CMake use to halt tests? Than you! On Thu, Oct 23, 2014 at 2:16 PM, digitalriptide digitalript...@gmail.com wrote: I have a number of tests configured in my CMakeLists.txt file, a few of which need to do some cleanup after running or if they are interrupted If I run make tests, and then send a signal (via ctrl+c, for example), however, these signals are not passed on to the test. Is it possible to configure CMake to pass signals on to the tests that are run? Cheers! -- 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://public.kitware.com/mailman/listinfo/cmake
[CMake] The new cmake.org web site
The new CMake web site looks fantastic! Even on my phone... Kudos to everybody involved in making it look pretty after all these years of, well, ahem, looking slightly less pretty... However, on this page: http://www.cmake.org/developer-resources/ The Dashboard icon is a broken link. 404. But, besides that, nice work! Cheers, David C. -- 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://public.kitware.com/mailman/listinfo/cmake
[Cmake-commits] CMake branch, master, updated. v3.0.2-2105-g2a668e2
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 2a668e20da7ba6ae380eb44219f285f13fd34981 (commit) via 80b19a7127e48dfc0e8cd0162359ae149e537638 (commit) via 4fdacedc27aa26501530fc85f887ab58b2800472 (commit) via 35ca4863aad357fbdb9d549e12d6c07f30ce9c54 (commit) via 58b2d760ee094e6f1a4a8701f86efcb81977b047 (commit) from 0213e6944ef471d7341eb1ac969656c68852f153 (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=2a668e20da7ba6ae380eb44219f285f13fd34981 commit 2a668e20da7ba6ae380eb44219f285f13fd34981 Merge: 0213e69 80b19a7 Author: Brad King brad.k...@kitware.com AuthorDate: Thu Oct 23 08:32:29 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Oct 23 08:32:29 2014 -0400 Merge topic 'doc-line-lengths' 80b19a71 Help/manual: Avoid long lines in code blocks 4fdacedc Help: Clarify formatting of CPACK_WIX_ACL documentation 35ca4863 Help: Wrap long ctest_submit signature line 58b2d760 Modules: Format documentation to avoid over-long preformatted lines --- Summary of changes: Help/command/ctest_submit.rst |6 ++- Help/manual/cmake-compile-features.7.rst |7 ++- Help/manual/cmake-developer.7.rst |3 +- Help/manual/cmake-generator-expressions.7.rst | 12 - Help/manual/cmake-toolchains.7.rst|5 +- Help/prop_inst/CPACK_WIX_ACL.rst |5 +- Modules/CMakeExpandImportedTargets.cmake |5 +- Modules/CMakeFindPackageMode.cmake| 27 ++ Modules/CMakePackageConfigHelpers.cmake | 50 ++ Modules/CMakeParseArguments.cmake |3 +- Modules/CMakePrintHelpers.cmake | 19 +++ Modules/DeployQt4.cmake | 12 +++-- Modules/FeatureSummary.cmake | 70 +++-- Modules/FindBacktrace.cmake | 24 + Modules/FindKDE3.cmake| 49 + Modules/FindOpenSceneGraph.cmake | 15 +++--- Modules/FindPNG.cmake | 23 Modules/FindPackageHandleStandardArgs.cmake | 28 +- Modules/FindQt4.cmake | 25 + Modules/FindRuby.cmake| 24 + Modules/FindSquish.cmake | 45 ++-- Modules/GNUInstallDirs.cmake | 57 Modules/WriteBasicConfigVersionFile.cmake |5 +- 23 files changed, 308 insertions(+), 211 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.0.2-2108-gb2a7f60
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 b2a7f60a4660ced5892e47eb1e7dd560313c340c (commit) via b91020f659ddc7d50868b3face370d9221c4c2dd (commit) via c48f6e1229b2487f98426eeced5da069a70efbf5 (commit) from 2a668e20da7ba6ae380eb44219f285f13fd34981 (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=b2a7f60a4660ced5892e47eb1e7dd560313c340c commit b2a7f60a4660ced5892e47eb1e7dd560313c340c Merge: 2a668e2 b91020f Author: Brad King brad.k...@kitware.com AuthorDate: Thu Oct 23 08:32:32 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Oct 23 08:32:32 2014 -0400 Merge topic 'xcode-ios-compiler-id' b91020f6 Xcode: Fix compiler id detection when code signing is required c48f6e12 Xcode: Fix compiler id detection for iOS tools (#15214) --- Summary of changes: Modules/CMakeDetermineCompilerId.cmake | 19 +-- Modules/CompilerId/Xcode-3.pbxproj.in |3 ++- 2 files changed, 19 insertions(+), 3 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.2-2167-g26b5708
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, next has been updated via 26b5708919e7784cfa9abd6b5f9eace499e3a5ce (commit) via b2a7f60a4660ced5892e47eb1e7dd560313c340c (commit) via 2a668e20da7ba6ae380eb44219f285f13fd34981 (commit) via 0213e6944ef471d7341eb1ac969656c68852f153 (commit) from 531195e9f309632580e4e694413ca863465a9531 (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=26b5708919e7784cfa9abd6b5f9eace499e3a5ce commit 26b5708919e7784cfa9abd6b5f9eace499e3a5ce Merge: 531195e b2a7f60 Author: Brad King brad.k...@kitware.com AuthorDate: Thu Oct 23 08:32:41 2014 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Thu Oct 23 08:32:41 2014 -0400 Merge branch 'master' into next --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.0.2-2111-g21c2dd8
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 21c2dd842b4323ac754c3bc76c6b8af25aa26fcc (commit) via 9c4551f274d4d502590c4728aeba112c92c13385 (commit) via 7d8879bb8da21216822e97e500fe3c873b791901 (commit) from b2a7f60a4660ced5892e47eb1e7dd560313c340c (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 - --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.2-2171-gaf134fe
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, next has been updated via af134fe2c3653881024f3cdc643adf4c5f994821 (commit) via 21c2dd842b4323ac754c3bc76c6b8af25aa26fcc (commit) via 9c4551f274d4d502590c4728aeba112c92c13385 (commit) via 7d8879bb8da21216822e97e500fe3c873b791901 (commit) from 26b5708919e7784cfa9abd6b5f9eace499e3a5ce (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=af134fe2c3653881024f3cdc643adf4c5f994821 commit af134fe2c3653881024f3cdc643adf4c5f994821 Merge: 26b5708 21c2dd8 Author: Brad King brad.k...@kitware.com AuthorDate: Thu Oct 23 08:33:32 2014 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Thu Oct 23 08:33:32 2014 -0400 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.2-2176-gb9c0886
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, next has been updated
via b9c08862c69eb2ffe4bc0751381b864db9607537 (commit)
via 84a2866d9f84a7d51378fc2ca725452db430c602 (commit)
via dccb6910c78a338e2b0f7c524aab6a78972bb104 (commit)
via a29953180c21ba0d56fb236eb58bafd40ae68961 (commit)
via 506151af519aa50594000d22c66c0620f026878f (commit)
from af134fe2c3653881024f3cdc643adf4c5f994821 (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=b9c08862c69eb2ffe4bc0751381b864db9607537
commit b9c08862c69eb2ffe4bc0751381b864db9607537
Merge: af134fe 84a2866
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Oct 23 14:39:29 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Oct 23 14:39:29 2014 -0400
Merge topic 'autorcc-depends' into next
84a2866d Speculative VS fix.
dccb6910 QtAutogen: Regenerate qrc files if their input changes (#15074)
a2995318 QtAutogen: Expand rccfiles into a vector early in the autogen
process.
506151af QtAutogen: Extract a GetRccExecutable method.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=84a2866d9f84a7d51378fc2ca725452db430c602
commit 84a2866d9f84a7d51378fc2ca725452db430c602
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Oct 20 23:57:10 2014 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Oct 23 20:35:57 2014 +0200
Speculative VS fix.
diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx
index 50d9299..929cbc0 100644
--- a/Source/cmQtAutoGenerators.cxx
+++ b/Source/cmQtAutoGenerators.cxx
@@ -377,6 +377,61 @@ bool cmQtAutoGenerators::InitializeAutogenTarget(cmTarget*
target)
}
}
}
+#endif
+
+ std::vectorstd::string rcc_output;
+ if(makefile-GetLocalGenerator()-GetGlobalGenerator()-GetName() == Ninja
+#if defined(_WIN32) !defined(__CYGWIN__)
+|| usePRE_BUILD
+#endif
+)
+{
+std::vectorcmSourceFile* srcFiles;
+target-GetConfigCommonSourceFiles(srcFiles);
+for(std::vectorcmSourceFile*::const_iterator fileIt = srcFiles.begin();
+fileIt != srcFiles.end();
+++fileIt)
+ {
+ cmSourceFile* sf = *fileIt;
+ std::string absFile = cmsys::SystemTools::GetRealPath(
+sf-GetFullPath().c_str());
+
+ std::string ext = sf-GetExtension();
+
+ if (target-GetPropertyAsBool(AUTORCC))
+{
+if (ext == qrc
+ !cmSystemTools::IsOn(sf-GetPropertyForUser(SKIP_AUTORCC)))
+ {
+ std::string basename = cmsys::SystemTools::
+ GetFilenameWithoutLastExtension(absFile);
+
+ std::string rcc_output_dir = target-GetSupportDirectory();
+ cmSystemTools::MakeDirectory(rcc_output_dir.c_str());
+ std::string rcc_output_file = rcc_output_dir;
+ rcc_output_file += /qrc_ + basename + .cpp;
+ rcc_output.push_back(rcc_output_file);
+
+ if (!cmSystemTools::IsOn(sf-GetPropertyForUser(GENERATED)))
+{
+if (qtMajorVersion == 5)
+ {
+ this-ListQt5RccInputs(sf, target, depends);
+ }
+else
+ {
+ this-ListQt4RccInputs(sf, depends);
+ }
+#if defined(_WIN32) !defined(__CYGWIN__)
+usePRE_BUILD = false;
+#endif
+}
+ }
+}
+ }
+}
+
+#if defined(_WIN32) !defined(__CYGWIN__)
if(usePRE_BUILD)
{
// Add the pre-build command directly to bypass the OBJECT_LIBRARY
@@ -394,51 +449,6 @@ bool cmQtAutoGenerators::InitializeAutogenTarget(cmTarget*
target)
#endif
{
cmTarget* autogenTarget = 0;
-std::vectorstd::string rcc_output;
-if(makefile-GetLocalGenerator()
- -GetGlobalGenerator()-GetName() == Ninja)
- {
- std::vectorcmSourceFile* srcFiles;
- target-GetConfigCommonSourceFiles(srcFiles);
- for(std::vectorcmSourceFile*::const_iterator fileIt = srcFiles.begin();
- fileIt != srcFiles.end();
- ++fileIt)
-{
-cmSourceFile* sf = *fileIt;
-std::string absFile = cmsys::SystemTools::GetRealPath(
- sf-GetFullPath().c_str());
-
-std::string ext = sf-GetExtension();
-
-if (target-GetPropertyAsBool(AUTORCC))
- {
- if (ext == qrc
- !cmSystemTools::IsOn(sf-GetPropertyForUser(SKIP_AUTORCC)))
-{
-std::string basename = cmsys::SystemTools::
-
[Cmake-commits] CMake branch, next, updated. v3.0.2-2180-gbf034ea
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, next has been updated
via bf034eac301d0242c5fe673bb062bbea95ac73f5 (commit)
via 1de20695659f40387671b10396d3d4b041c4e315 (commit)
via 7051b42b6bf090d31f4fd41257e3ba127e1137ce (commit)
via a718b089b0e2ad6734eca170531884ee01c8596a (commit)
from b9c08862c69eb2ffe4bc0751381b864db9607537 (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=bf034eac301d0242c5fe673bb062bbea95ac73f5
commit bf034eac301d0242c5fe673bb062bbea95ac73f5
Merge: b9c0886 1de2069
Author: Chuck Atkins chuck.atk...@kitware.com
AuthorDate: Thu Oct 23 17:14:08 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Oct 23 17:14:08 2014 -0400
Merge topic 'refactor-search-path-construction' into next
1de20695 Use containers of labeled search paths instead of individual
members
7051b42b Encapsulate search path manipulation functions into a seperate
class.
a718b089 Refactor and seperate search path construction for find commands
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1de20695659f40387671b10396d3d4b041c4e315
commit 1de20695659f40387671b10396d3d4b041c4e315
Author: Chuck Atkins chuck.atk...@kitware.com
AuthorDate: Fri Oct 17 13:07:26 2014 -0400
Commit: Chuck Atkins chuck.atk...@kitware.com
CommitDate: Thu Oct 23 17:11:44 2014 -0400
Use containers of labeled search paths instead of individual members
Manage classes of search paths in labeled containers. This removes the
need to have a seperate member variable for each type of search path, but
also allows path types to be grouped togethor in various different ways
and manipulated as subsets of the full set of search paths.
diff --git a/Source/cmBootstrapCommands1.cxx b/Source/cmBootstrapCommands1.cxx
index 29d3671..5502609 100644
--- a/Source/cmBootstrapCommands1.cxx
+++ b/Source/cmBootstrapCommands1.cxx
@@ -43,7 +43,6 @@
#include cmExecuteProcessCommand.cxx
#include cmExternalMakefileProjectGenerator.cxx
#include cmFindBase.cxx
-#include cmSearchPath.cxx
#include cmFindCommon.cxx
#include cmFileCommand.cxx
#include cmFindFileCommand.cxx
@@ -53,6 +52,8 @@
#include cmFindProgramCommand.cxx
#include cmForEachCommand.cxx
#include cmFunctionCommand.cxx
+#include cmPathLabel.cxx
+#include cmSearchPath.cxx
void GetBootstrapCommands1(std::listcmCommand* commands)
{
diff --git a/Source/cmFindBase.cxx b/Source/cmFindBase.cxx
index 52f04ad..beb6dde 100644
--- a/Source/cmFindBase.cxx
+++ b/Source/cmFindBase.cxx
@@ -225,102 +225,112 @@ void cmFindBase::ExpandPaths()
//
void cmFindBase::FillCMakeEnvironmentPath()
{
+ cmSearchPath paths = this-LabeledPaths[PathLabel::CMakeEnvironment];
+
// Add CMAKE_*_PATH environment variables
std::string var = CMAKE_;
var += this-CMakePathName;
var += _PATH;
- this-CMakeEnvironmentPaths.AddEnvPrefixPath(CMAKE_PREFIX_PATH);
- this-CMakeEnvironmentPaths.AddEnvPath(var);
+ paths.AddEnvPrefixPath(CMAKE_PREFIX_PATH);
+ paths.AddEnvPath(var);
if(this-CMakePathName == PROGRAM)
{
-this-CMakeEnvironmentPaths.AddEnvPath(CMAKE_APPBUNDLE_PATH);
+paths.AddEnvPath(CMAKE_APPBUNDLE_PATH);
}
else
{
-this-CMakeEnvironmentPaths.AddEnvPath(CMAKE_FRAMEWORK_PATH);
+paths.AddEnvPath(CMAKE_FRAMEWORK_PATH);
}
- this-CMakeEnvironmentPaths.AddSuffixes(this-SearchPathSuffixes);
+ paths.AddSuffixes(this-SearchPathSuffixes);
}
//
void cmFindBase::FillCMakeVariablePath()
{
+ cmSearchPath paths = this-LabeledPaths[PathLabel::CMake];
+
// Add CMake varibles of the same name as the previous environment
// varibles CMAKE_*_PATH to be used most of the time with -D
// command line options
std::string var = CMAKE_;
var += this-CMakePathName;
var += _PATH;
- this-CMakeVariablePaths.AddCMakePrefixPath(CMAKE_PREFIX_PATH);
- this-CMakeVariablePaths.AddCMakePath(var);
+ paths.AddCMakePrefixPath(CMAKE_PREFIX_PATH);
+ paths.AddCMakePath(var);
if(this-CMakePathName == PROGRAM)
{
-this-CMakeVariablePaths.AddCMakePath(CMAKE_APPBUNDLE_PATH);
+paths.AddCMakePath(CMAKE_APPBUNDLE_PATH);
}
else
{
-this-CMakeVariablePaths.AddCMakePath(CMAKE_FRAMEWORK_PATH);
+paths.AddCMakePath(CMAKE_FRAMEWORK_PATH);
}
- this-CMakeVariablePaths.AddSuffixes(this-SearchPathSuffixes);
+ paths.AddSuffixes(this-SearchPathSuffixes);
}
//
[Cmake-commits] CMake branch, master, updated. v3.0.2-2112-gfbc2a38
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 fbc2a384d8d137f2332d0f8de7a23edfac84a361 (commit) from 21c2dd842b4323ac754c3bc76c6b8af25aa26fcc (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=fbc2a384d8d137f2332d0f8de7a23edfac84a361 commit fbc2a384d8d137f2332d0f8de7a23edfac84a361 Author: Kitware Robot kwro...@kitware.com AuthorDate: Fri Oct 24 00:01:08 2014 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Fri Oct 24 00:01:08 2014 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index bcf8d22..b764a3f 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 1) -set(CMake_VERSION_PATCH 20141023) +set(CMake_VERSION_PATCH 20141024) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
