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
