Re: [cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY
On 05/12/2015 07:23 AM, James Bigler wrote: OK, thanks. I still think that if there is a difference in behavior for Makefile generators between MAIN_DEPENDENCY and DEPENDENCY there is a bug in CMake. Perhaps there needs to be bug filed for that. Here's the documentation: In makefile terms this creates a new target in the following form:: OUTPUT: MAIN_DEPENDENCY DEPENDS COMMAND For a makefile, there shouldn't be a difference between the dependency coming in on MAIN_DEPENDENCY or DEPENDENCY. CMake is doing something else with that property. I would prefer that too but the add_custom_command() implementation which handles MAIN_DEPENDENCY and DEPENDENCY and attaches commands to source files is common to all generators. Treating MAIN_DEPENDENCY and DEPENDENCY the same for Makefiles in this case would break existing projects (when using the Makefile generators) when they list the source file named by MAIN_DEPENDENCY but not the source file named by OUTPUT since then the custom command would not get emitted at all. 2. I'm curious why this causes a problem. It seems to me that dummy.cpp should be present by the time the add_custom_command is even run, Yes, it is. so why would it care whether it was created by CMake or anything else? That isn't the issue. The test case failure depends on the presence of the custom command but the custom command is not involved in creation of dummy.cpp; it only uses it as input. Due to MAIN_DEPENDENCY the custom command is attached to dummy.cpp. I think the issue is due to cmake trying to attach the command used to compile dummy.cpp itself as a custom command as well. [1] Nils [1] http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalGenerator.cxx;h=88c88cd133a753fc319a785e116fdb8e6d5fd94a;hb=HEAD#l580 -- 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] [CMake 0015565]: Add support for openjdk 8
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15565 == Reported By:Felix Geyer Assigned To: == Project:CMake Issue ID: 15565 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-05-12 13:41 EDT Last Modified: 2015-05-12 13:41 EDT == Summary:Add support for openjdk 8 Description: cmake 3.2.2 fails to detect openjdk-8 (8u45-b14-2) on Debian unstable. CMake Warning at /usr/share/cmake-3.2/Modules/FindJava.cmake:145 (message): regex not supported: openjdk version 1.8.0_45-internal OpenJDK Runtime Environment (build 1.8.0_45-internal-b14) OpenJDK 64-Bit Server VM (build 25.45-b02, mixed mode). Please report The attached patch fixes this. == Issue History Date ModifiedUsername FieldChange == 2015-05-12 13:41 Felix GeyerNew Issue 2015-05-12 13:41 Felix GeyerFile Added: cmake_openjdk8_debian.diff == -- 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] Proper way to find 64-bit version of a library (or specifically OSG)
Hi all, I'm wondering what the proper way is to go about finding 64-bit versions of a library. My situation is that I have built OpenSceneGraph 64-bit and installed it. The libraries end up in /usr/whatever/lib64. But to be able to find the libraries I needed to modify Modules/FindOpenThreads.cmake and Modules/Findosg_functions.cmake to also search lib64 suffixes (modified PATH_SUFFIXES). Is this the way to go? Should I submit a patch ? Or is there some higher level way to make find_package look for 64-bit libraries that is more appropriate ? And yes, I'm on CMake master as of may12. Thanks Mattias -- 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] [CMake 0015563]: ABI failures are not treated as a fatal error
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15563 == Reported By:Alex Lamaison Assigned To: == Project:CMake Issue ID: 15563 Category: CMake Reproducibility:sometimes Severity: minor Priority: normal Status: new == Date Submitted: 2015-05-12 06:18 EDT Last Modified: 2015-05-12 06:18 EDT == Summary:ABI failures are not treated as a fatal error Description: With Visual Studio 2005/2008 ABI detection sometimes fails because the path to the source file is too long. When that happens, CMake continues configuring and doesn't treat it as a fatal error. Shouldn't building be aborted if ABI tests fail? What effect might it have on the binaries that are built? Steps to Reproduce: Install CMake at the default location. Create a CMake project at a directory several steps down from C:\, e.g C:\Users\MyUsername\Project\My\Project. Configure the project with CMake to use Visual Studio 2005 or 2008 as generator. Observe log output like: 1-- The C compiler identification is MSVC 14.0.50727 1-- The CXX compiler identification is MSVC 14.0.50727 1-- Check for working C compiler using: Visual Studio 8 2005 Win64 1-- Check for working C compiler using: Visual Studio 8 2005 Win64 -- works 1-- Detecting C compiler ABI info 1-- Detecting C compiler ABI info - failed 1-- Check for working CXX compiler using: Visual Studio 8 2005 Win64 1-- Check for working CXX compiler using: Visual Studio 8 2005 Win64 -- works 1-- Detecting CXX compiler ABI info 1-- Detecting CXX compiler ABI info - failed Observe that configuration continues after the ABI check failure and reports success. The only way to notice that ABI detection failed is to grep the log. Additional Information: The reason the ABI step fails with older visual studio is that CMake adds the full path to CMakeCXXCompilerABI.cpp as a RelativePath in the VS project. For example, C:\Program Files (x86)\CMake\share\cmake-3.2\Modules\CMakeCXXCompilerABI.cpp. Visual Studio converts all paths to be relative to the build directory. Assuming a build path of C:\Users\MyUsername\Project\My\Project\bin, VS tries to open ..\..\..\..\..\Program Files (x86)\CMake\share\cmake-3.2\Modules\CMakeCXXCompilerABI.cpp and fails because this is longer than Windows path limits. A workaround for this would be for CMake to copy CMakeCXXCompilerABI.cpp to the binary directory, the way it does for the source file it uses to determine if the compiler is working. See https://github.com/ruslo/hunter/issues/121#issuecomment-101219535 for more history on this issue. == Issue History Date ModifiedUsername FieldChange == 2015-05-12 06:18 Alex Lamaison New Issue == -- 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] find_package config mode search path rule #5 error prone
On 05/07/2015 08:40 AM, Ruslan Baratov via cmake-developers wrote: On 07-May-15 00:00, Tamás Kenéz wrote: There are great and proper ways to use the products of a project in a dependent project. Opening the project in cmake-gui to expose the byproduct of a config-module configuration+installation process in the binary dir, is not of them. Totally agree, since I am a reporter of this bug: http://public.kitware.com/Bug/view.php?id=14781 As far as I know it works only for GUI version and only on Windows. So does anybody really use such workflow regularly? This behavior has been there since find_package was first written, but since then we gained much better capabilities and alternatives: find_package: Drop search in recent cmake-gui locations http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1506f9ca -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] [CPackIFW] Adding QtIFW 2.0 Support (Technical Preview)
Online repository updated! Meet CMake 3.2.20150512 :-) Online installers for Linux and Windows are available at the links below. Dear developers, I have just one question: anyone uses CPackIFW or QtIFW? 29.04.2015, 16:57, Konstantin Podsvirov konstan...@podsvirov.pro: Hello dear developers! Recently we learned the good news about the release QtIFW 2.0: http://blog.qt.io/blog/2015/04/07/qt-installer-framework-2-0-released And I too was delighted at once. But then I was faced with an unstable work of the installer on Windows and it upset me. I think QtIFW 2.0 as quickly as possible became better - you need to actively use and test in various situations. On adding support QtIFW 2.0 now I work in a topic branch cpack-ifw-develop: http://git.podsvirov.pro/?p=kitware/cmake.git;a=shortlog;h=refs/heads/cpack-ifw-develop All those interested can get acquainted with the code, but I want to submit online installers CMake based on this code, and built by ourselves :-) : Two installer collected in Debian 8: http://ifw.podsvirov.pro/cmake/cmake-master-i386-online.run http://ifw.podsvirov.pro/cmake/cmake-master-amd64-online.run Installer And two collected in Windows 7: http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe Working with cpack-ifw-develop I will periodically update the online repository. The presented version of CMake (CPackIFW) already know how to work with QtIFW 2.0 but not in full. I would like to know from users CPackIFW and QtIFW what functionality demanded in the first place. Suggest we discuss the quality of the generated configuration files. Also available documentation: http://ifw.podsvirov.pro/cmake/doc/sphinx http://ifw.podsvirov.pro/cmake/doc/doxygen When I decide that the support QtIFW 2.0 has reached an acceptable state, we will begin work on the integration of changes. Waiting for answers, questions, suggestions! -- Regards, Konstantin Podsvirov 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] [PATCH v3] FindHDF5.cmake HDF5_VERSION Support
On 05/12/2015 09:58 AM, Brad King wrote: Thanks. Applied with minor tweaks to the commit message plus a test suite update: FindHDF5: Add version support http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c1150734 I revised the copyright block to fix the ModuleNotices test: FindHDF5: Add version support http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=58d6709e -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] [PATCH v3] FindHDF5.cmake HDF5_VERSION Support
On 05/11/2015 09:22 AM, Huebl, Axel wrote: This commit adds VERSION support for HDF5 from the same sources as it adds the HDF5_IS_PARALLEL flag. Thanks. Applied with minor tweaks to the commit message plus a test suite update: FindHDF5: Add version support http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c1150734 -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] [CMake 0015564]: MIPS is a CPU (fix mipsel support)
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15564 == Reported By:Mathieu Malaterre Assigned To: == Project:CMake Issue ID: 15564 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-05-12 11:15 EDT Last Modified: 2015-05-12 11:15 EDT == Summary:MIPS is a CPU (fix mipsel support) Description: The code assume that __MIPS__ imply big endian, which is incorrect. See attached patch for details. Orig ref: https://bugs.debian.org/785126 == Issue History Date ModifiedUsername FieldChange == 2015-05-12 11:15 Mathieu MalaterreNew Issue 2015-05-12 11:15 Mathieu MalaterreFile Added: mipsel.patch == -- 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
