Re: [cmake-developers] [CMake] 2.8.11-rc3 generator expression error
Stephen Kelly wrote: It can probably be refactored to bypass the genex evaluation though. The refactoring I described can be done in the future I think, but doesn't really solve the bug anyway, because it is evaluation of the generator expression for the target itself which is causing problems here. I've force-pushed the fix-multi-config-tll-include-dirs branch with a more- simple fix for this issue to my clone. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014119]: infinite loop compiler chancged: change error message to delete CMakeFiles folder to try fix this
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14119 == Reported By:Shimon Doodkin Assigned To: == Project:CMake Issue ID: 14119 Category: (No Category) Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2013-04-29 07:06 EDT Last Modified: 2013-04-29 07:06 EDT == Summary:infinite loop compiler chancged: change error message to delete CMakeFiles folder to try fix this Description: http://www.mail-archive.com/cmake@cmake.org/msg44765.html http://public.kitware.com/Bug/view.php?id=13756 change the error message: You have changed variables that require your cache to be deleted. Configure will be re-run and you may have to reset some variables. The following variables have changed: add to it: Delete CMakeFiles folder to try fix this (not CMakeCache.txt) solution was: After this behavior, you have to manually delete the CMakeFiles directory (not CMakeCache.txt) to recover. == Issue History Date ModifiedUsername FieldChange == 2013-04-29 07:06 Shimon Doodkin New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Code Changes to support C++ Windows Forms
I created a topic called WindowsFormsResx following the developer guide instructions and have committed my staged changes and a test project. I don't know how to send out a link to this, but would be happy to do so if someone pointed me in the right direction. - John On 2013-04-28 20:46, Jean-Christophe Fillion-Robin wrote: Hi John, Seems you forgot to send a link to the associated topic. Jc On Sun, Apr 28, 2013 at 10:20 PM, john.farr...@helleboreconsulting.com wrote: Hello all! New CMake developer here! I have modified the latest version of CMake from Git to be able to use .resx files and integrate them into Visual Studio, perform the correct associations, and enable use of the Visual Studio designer for Windows Forms applications after a solution and projects are configured by CMake. The changes were fairly minimal, but really help me out! I have a project that is mostly cross-platform, but there are a few plugins that are windows-specific. I wanted to use CMake to build and manage the project, but when CMake configured the windows GUI's, I would lose all of the designer information, which is totally unacceptable for ever having to make a change to the GUI. This change is targeted specifically at C++ Windows Forms applications using CLI. I'd like to push these changes up, so feedback is welcome! - John Farrier -- Powered by www.kitware.com [1] Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html [2] Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ [3] Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers [4] -- +1 919 869 8849 Links: -- [1] http://www.kitware.com [2] http://www.kitware.com/opensource/opensource.html [3] http://www.cmake.org/Wiki/CMake_FAQ [4] http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] 2.8.11-rc3 generator expression error
On 04/29/2013 06:29 AM, Stephen Kelly wrote: I've force-pushed the fix-multi-config-tll-include-dirs branch with a more- simple fix for this issue to my clone. Okay, that looks good. Please rebase on the partial fix I merged last week so we can test it in 'next'. I'll squash all that together later. Also I realized my local topic using GetLinkInformation is wrong because it includes usage requirements from everything linked, not just from the link *interface* closure. I'll drop that one in favor of yours. While working through all of the above I realized that AppendTllIncludes and LinkInterfaceIncludeDirectoriesEntries are not safe. Users can re-write the LINK_LIBRARIES property and those other structures will not be updated. IIUC they only exist to provide a backtrace for include directory entries. Please drop them for now at the expense of the backtraces which can be restored later by tracking the backtraces of all tll() link information (similar to tid() now). Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Code Changes to support C++ Windows Forms
Hi John, Seems your topic isn't available on the CMake stage: http://cmake.org/gitweb?p=stage/cmake.git I would suggest you push your topic on github instead. The stage is used by module maintainer or CMake core developers [1] Hth Jc [1] http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer On Mon, Apr 29, 2013 at 8:36 AM, john.farr...@helleboreconsulting.comwrote: I created a topic called WindowsFormsResx following the developer guide instructions and have committed my staged changes and a test project. I don't know how to send out a link to this, but would be happy to do so if someone pointed me in the right direction. - John On 2013-04-28 20:46, Jean-Christophe Fillion-Robin wrote: Hi John, Seems you forgot to send a link to the associated topic. Jc On Sun, Apr 28, 2013 at 10:20 PM, john.farrier@**helleboreconsulting.comjohn.farr...@helleboreconsulting.com wrote: Hello all! New CMake developer here! I have modified the latest version of CMake from Git to be able to use .resx files and integrate them into Visual Studio, perform the correct associations, and enable use of the Visual Studio designer for Windows Forms applications after a solution and projects are configured by CMake. The changes were fairly minimal, but really help me out! I have a project that is mostly cross-platform, but there are a few plugins that are windows-specific. I wanted to use CMake to build and manage the project, but when CMake configured the windows GUI's, I would lose all of the designer information, which is totally unacceptable for ever having to make a change to the GUI. This change is targeted specifically at C++ Windows Forms applications using CLI. I'd like to push these changes up, so feedback is welcome! - John Farrier -- Powered by www.kitware.com [1] Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html[2] Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ[3] Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-**bin/mailman/listinfo/cmake-**developershttp://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers[4] -- +1 919 869 8849 Links: -- [1] http://www.kitware.com [2] http://www.kitware.com/**opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html [3] http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ [4] http://public.kitware.com/cgi-**bin/mailman/listinfo/cmake-** developershttp://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- +1 919 869 8849 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Code Changes to support C++ Windows Forms
Done and Pull Request sent. Visual Studio C++ Windows Forms Designer Support Thanks. I look forward to helping this get into the CMake baseline! - John On 2013-04-29 08:08, Jean-Christophe Fillion-Robin wrote: Hi John, Seems your topic isn't available on the CMake stage: http://cmake.org/gitweb?p=stage/cmake.git [6] I would suggest you push your topic on github instead. The stage is used by module maintainer or CMake core developers [1] Hth Jc [1] http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer [7] On Mon, Apr 29, 2013 at 8:36 AM, john.farr...@helleboreconsulting.com wrote: I created a topic called WindowsFormsResx following the developer guide instructions and have committed my staged changes and a test project. I don't know how to send out a link to this, but would be happy to do so if someone pointed me in the right direction. - John On 2013-04-28 20:46, Jean-Christophe Fillion-Robin wrote: Hi John, Seems you forgot to send a link to the associated topic. Jc On Sun, Apr 28, 2013 at 10:20 PM, john.farr...@helleboreconsulting.com wrote: Hello all! New CMake developer here! I have modified the latest version of CMake from Git to be able to use .resx files and integrate them into Visual Studio, perform the correct associations, and enable use of the Visual Studio designer for Windows Forms applications after a solution and projects are configured by CMake. The changes were fairly minimal, but really help me out! I have a project that is mostly cross-platform, but there are a few plugins that are windows-specific. I wanted to use CMake to build and manage the project, but when CMake configured the windows GUI's, I would lose all of the designer information, which is totally unacceptable for ever having to make a change to the GUI. This change is targeted specifically at C++ Windows Forms applications using CLI. I'd like to push these changes up, so feedback is welcome! - John Farrier -- Powered by www.kitware.com [1] [1] Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html [2] [2] Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ [3] [3] Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers [4] [4] -- +1 919 869 8849 [5] Links: -- [1] http://www.kitware.com [1] [2] http://www.kitware.com/opensource/opensource.html [2] [3] http://www.cmake.org/Wiki/CMake_FAQ [3] [4] http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers [4] -- +1 919 869 8849 Links: -- [1] http://www.kitware.com [2] http://www.kitware.com/opensource/opensource.html [3] http://www.cmake.org/Wiki/CMake_FAQ [4] http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers [5] tel:%2B1%20919%20869%208849 [6] http://cmake.org/gitweb?p=stage/cmake.git [7] http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Please review CXXFeatures.cmake
On Sunday 28 April 2013, Rolf Eike Beer wrote: One question I see increasingly often is how do I test for C++11 support or for specific parts of that. For 2.8.12 I plan to include the check module I wrote for that a while back, and that I have reworked in the last weeks. You can find the current state in the rework branch of this repository: git://anongit.kde.org/scratch/dakon/cmake-cxx11 Line 75: if (CROSS_COMPILING) Do you mean if(CMAKE_CROSSCOMPILING) ? Is the try_run() in all cases necessary ? It would be better if a try_compile() would suffice, that's faster and then it works the same way when cross-compiling and when not. Line 139: if (NOT CXXFEATURES_FIND_COMPONENTS) set(CXXFEATURES_FIND_COMPONENTS ${_CXX_ALL_FEATURES}) endif () foreach (_cxx_feature IN LISTS _CXX_ALL_FEATURES) cxx_check_feature(${_cxx_feature} ${FEATURE_NAME}) endforeach (_cxx_feature) Is this how it is supposed to be or should the foreach() loop run over CXXFEATURES_FIND_COMPONENTS ? I didn't try, but it seems it can fail if I give an unknown component. Is there a check that only known components (CXX features) are requested ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] RFC: pretty/HTML output in test logs in ctest/cdash
On Thursday 18 April 2013, Alexander Neundorf wrote: Hi, attached are two patches for ctest and cdash from Volkan (on CC). They are not ready for inclusion, but before we continue to work in this, we'd like to get some comments whether this is a good idea, the right approach, etc. So, here we go. We are using cdash a lot, and for many of our tests the log is quite verbose and somewhat hard to read. When looking for the reason why a test failed, it can be somewhat hard to find the line which contains ERROR. Also, a lot of stuff is repeated every line, which also makes the log harder to read, e.g. the directory part of the file where the log came from: timestamp /some/where/deep/in/a/subdir/test.py: Something... timestamp /some/where/deep/in/a/subdir/test.py: happend... timestamp /some/where/deep/in/a/subdir/test.py: here... timestamp /some/where/deep/in/a/subdir/test.py: ... The directory part is actually so wide that we have to scroll to see actual text. So, to help with this, we came up with the idea to use HTML to format the log so that it becomes easier to read. The attached patch for ctest adds a new test property GENERATE_HTML, and if this is enabled, ctest generates HTML. It searches the lines which made the test fail and colors them red, and the lines which make a test pass are colored green. This makes it easier to find the fail/succeed lines. (In the patch the fail strings are still hardcoded, this would have to use the respective test property.) On the cdash side, if /span is found in the log, it is considered HTML and not escaped. I guess this should be done in a different way, which does not involve parsing the log text. Comments so far ? For making our log lines shorter, we are not sure yet how to do that. We could add support for squish XML to ctest, so that ctest reads the squish XML and converts it to HTML which is in some way shorter, maybe a HTML table, or something. Or we could add a test property with a regular expression, if that regexp matches, ctest replaces it with a shorter version or something. Or we could modify our test scripts so that they already generate the pretty HTML, which ctest then simply sends to cdash. That's the ideas we have so far, but it doesn't feel quite right yet. So, what do you think ? Any comments ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] ADDITIONAL_MAKE_CLEAN_FILES only works in Makefile generators / automoc cleaning problem
Hi, in automoc, for every target foo a foo_automoc target is created, and for each of those a file foo_automoc.cpp is created. When this file does not exist, automoc reruns and all moc files should be regenerated. To achieve this, I added this file in cmQtAutomoc.cxx to the ADDITIONAL_MAKE_CLEAN_FILES property, so it is removed on make clean. Now after some emails on the cmake list, it seems ADDITIONAL_MAKE_CLEAN_FILES is used only by the Makefile-generators, but not by e.g. the VS generators ? The target is created using cmMakefile::AddUtilityCommand(). What would be the recommended way to add a generated file, so that it is removed when cleaning ? Do I need to create a cmSourceFile and set it to GENERATED ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ADDITIONAL_MAKE_CLEAN_FILES only works in Makefile generators / automoc cleaning problem
On 04/29/2013 03:05 PM, Alexander Neundorf wrote: Now after some emails on the cmake list, it seems ADDITIONAL_MAKE_CLEAN_FILES is used only by the Makefile-generators, but not by e.g. the VS generators ? VS does its own cleaning of the build outputs it knows. The target is created using cmMakefile::AddUtilityCommand(). What would be the recommended way to add a generated file, so that it is removed when cleaning ? Do I need to create a cmSourceFile and set it to GENERATED ? VS needs to know that the file is the output of a custom command. In order for CMake to tell VS about this, the file needs to be listed as an OUTPUT in add_custom_command. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Please review CXXFeatures.cmake
Alexander Neundorf wrote: On Sunday 28 April 2013, Rolf Eike Beer wrote: One question I see increasingly often is how do I test for C++11 support or for specific parts of that. For 2.8.12 I plan to include the check module I wrote for that a while back, and that I have reworked in the last weeks. You can find the current state in the rework branch of this repository: git://anongit.kde.org/scratch/dakon/cmake-cxx11 Is the try_run() in all cases necessary ? It would be better if a try_compile() would suffice, that's faster and then it works the same way when cross-compiling and when not. I'm not sure about this, but the other ones I consider real bugs. Thanks for catching them, will fix soon. Eike -- signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Please review CXXFeatures.cmake
On Monday 29 April 2013, Rolf Eike Beer wrote: Alexander Neundorf wrote: On Sunday 28 April 2013, Rolf Eike Beer wrote: One question I see increasingly often is how do I test for C++11 support or for specific parts of that. For 2.8.12 I plan to include the check module I wrote for that a while back, and that I have reworked in the last weeks. You can find the current state in the rework branch of this repository: git://anongit.kde.org/scratch/dakon/cmake-cxx11 Is the try_run() in all cases necessary ? It would be better if a try_compile() would suffice, that's faster and then it works the same way when cross-compiling and when not. I'm not sure about this, but the other ones I consider real bugs. Thanks for catching them, will fix soon. Or IOW: if possible at all, try really hard to get away with only try_compile(), i.e. avoid try_run(). Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014121]: Custom command errors are hidden when CTest launchers are used with Ninja
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14121 == Reported By:Nils Gladitz Assigned To: == Project:CMake Issue ID: 14121 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-04-29 16:51 EDT Last Modified: 2013-04-29 16:51 EDT == Summary:Custom command errors are hidden when CTest launchers are used with Ninja Description: I couldn't get any build errors from custom commands on my CDash dashboard when using Ninja with CTest launchers. Neither are there errors from custom commands with failure exit status nor from those with output matched by CTEST_CUSTOM_ERROR_MATCH. Steps to Reproduce: I've set up a test project for which I tested make and ninja with and without launchers. CTEST_CUSTOM_ERROR_MATCH is set to FooBar. The project contains three custom commands with the following outputs and exit codes: CustomCommand1: this is a FooBar message (exit success) CustomCommand2: this is a fatal error (exit failure) CustomCommand3: this is a FooBar fatal error (exit failure) These are the results that I got (numbers in braces indicate which custom commands produce output visible on CDash): Ninja (Launchers enabled): 0 Build Errors Ninja (Launchers disabled): 4 Build Errors (1, 2, 3) Unix Makefiles (Launchers enabled): 2 Build Errors (2, 3) Unix Makefiles (Launchers disabled): 4 Build Errors (1, 2, 3) CTEST_CUSTOM_ERROR_MATCH seems to only work with launchers disabled with Makefiles as well so I assume this is by design (though unexpected). At the very least the exit status in the Ninja + Launchers case should be evaluated as it is with Makefiles. == Issue History Date ModifiedUsername FieldChange == 2013-04-29 16:51 Nils Gladitz New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ADDITIONAL_MAKE_CLEAN_FILES only works in Makefile generators / automoc cleaning problem
On Monday 29 April 2013, Brad King wrote: On 04/29/2013 03:05 PM, Alexander Neundorf wrote: Now after some emails on the cmake list, it seems ADDITIONAL_MAKE_CLEAN_FILES is used only by the Makefile-generators, but not by e.g. the VS generators ? VS does its own cleaning of the build outputs it knows. The target is created using cmMakefile::AddUtilityCommand(). What would be the recommended way to add a generated file, so that it is removed when cleaning ? Do I need to create a cmSourceFile and set it to GENERATED ? VS needs to know that the file is the output of a custom command. In order for CMake to tell VS about this, the file needs to be listed as an OUTPUT in add_custom_command. This is now in the AutomocFixCleaningHandling branch. It would be nice if you could have a look at it. Thanks Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] Intel compiler with Visual Studio
Hello, we want to use the Visual Studio IDE with the Intel C++ compiler. The Intel compiler integrates neatly with the IDE, you right click on a project or solution and select use Intel C++ or use Visual C++ to switch between compilers. I have added the following option to our CMake file: option( INTEL_COMPILER Use the Intel compiler. ON ) Currently I use this flag to decide which set of boost libraries to link to. I also want to use this flag to tell the IDE which compiler to use however I cannot find a way to do this. It is not nice to have to remember to manually switch to the Intel compiler after running CMake, especially as this does a clean of your solution. Does anyone know please a way to get CMake to tell Visual Studio which complier to use? Note when you select the Intel complier for a particular project in the IDE a PlatformToolsetIntel C++ Compiler XE 13.0/PlatformToolset get added to the PropertyGroup sections of the project's .vcxproj file. Thank you, John W E-mail confidentiality. This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system. Spirent Communications plc Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom. Tel No. +44 (0) 1293 767676 Fax No. +44 (0) 1293 767677 Registered in England Number 470893 Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom. Or if within the US, Spirent Communications, 26750 Agoura Road, Calabasas, CA, 91302, USA. Tel No. 1-818-676- 2300 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem with CMAKE_AUTOMOC files not being regenerated or cleaned
I added these lines: set_directory_properties( PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES ${CMAKE_CURRENT_BINARY_DIR}/abc.txt ) # check the location where abc.txt is supposed to be deleted from message(CURRENT_BINARY_DIR: ${CMAKE_CURRENT_BINARY_DIR}) to the end of my CMakeLists.txt and then created abc.txt in the cmake build directory. I can confirm that the abc.txt file was not deleted by a clean solution. I tried this with Visual Studio 2012 and Visual Studio 2008 (both installs are the Express editions) and the results were identical. -- Glenn On 28 April 2013 11:53, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Sunday 28 April 2013, Glenn Coombs wrote: No, cleaning the project didn't remove that file. Can you manually set the ADDITIONAL_MAKE_CLEAN_FILES directory property to some file and check whether this file is deleted when you clean ? Something like set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES ${CMAKE_CURRENT_BINARY_DIR}/abc.txt ) then just create such a file in the build dir, and clean. It should be removed then. If it is not, then this is the reason why clean doesn't clean automoc properly. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] FindCUDA fails to find libcuda.so
Hi all, I noticed that FindCUDA.cmake fails to locate libcuda.so on at least two different platforms: Ubuntu 12.10 and CentOS 6.3 using Cluster Manager v5.2. I can persuade FindCUDA.cmake to search for this library by explicitly setting the environment variable CUDA_LIB_PATH, and then it finds it. However, IMHO, using this trick should only be necessary as a last resort. Is this a bug? Best regards, Marcel Loose. attachment: loose.vcf-- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindCUDA fails to find libcuda.so
Can you provide what Cuda version FindCuda is failing to find, and where Cluster Manager is installing the CUDA toolkit and library? On Mon, Apr 29, 2013 at 7:38 AM, Marcel Loose lo...@astron.nl wrote: Hi all, I noticed that FindCUDA.cmake fails to locate libcuda.so on at least two different platforms: Ubuntu 12.10 and CentOS 6.3 using Cluster Manager v5.2. I can persuade FindCUDA.cmake to search for this library by explicitly setting the environment variable CUDA_LIB_PATH, and then it finds it. However, IMHO, using this trick should only be necessary as a last resort. Is this a bug? Best regards, Marcel Loose. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindCUDA fails to find libcuda.so
Hi, It fails to find CUDA 5.0. See below. $ env | grep CUDA CUDA_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35 CUDA_INC_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35 CUDA_SDK=/cm/shared/apps/cuda50/sdk/5.0.35 CUDA_CACHE_DISABLE=1 CUDA_INSTALL_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35 CUDA_ROOT=/cm/local/apps/cuda50/libs/304.54 $ cat ../CMakeLists.txt cmake_minimum_required(VERSION 2.8) project(CheckCUDALibs) find_package(CUDA) message(STATUS CUDA_LIBRARIES = ${CUDA_LIBRARIES}) $ cmake .. -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Found CUDA: /cm/shared/apps/cuda50/toolkit/5.0.35 (found version 5.0) -- CUDA_LIBRARIES = /cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so -- Configuring done -- Generating done -- Build files have been written to: /home/loose/temp/cmake/cuda/build $ CUDA_LIB_PATH=$CUDA_ROOT/lib cmake .. -- CUDA_LIBRARIES = /cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so;/cm/local/apps/cuda50/libs/304.54/lib64/libcuda.so -- Configuring done -- Generating done -- Build files have been written to: /home/loose/temp/cmake/cuda/build Only when explicitly setting CUDA_LIB_PATH, libcuda.so is found. BTW: On Ubuntu I also need to set CUDA_LIB_PATH, but then to /usr/lib/nvidia-current. Regards, Marcel Loose. On 29/04/13 15:36, Robert Maynard wrote: Can you provide what Cuda version FindCuda is failing to find, and where Cluster Manager is installing the CUDA toolkit and library? On Mon, Apr 29, 2013 at 7:38 AM, Marcel Loose lo...@astron.nl wrote: Hi all, I noticed that FindCUDA.cmake fails to locate libcuda.so on at least two different platforms: Ubuntu 12.10 and CentOS 6.3 using Cluster Manager v5.2. I can persuade FindCUDA.cmake to search for this library by explicitly setting the environment variable CUDA_LIB_PATH, and then it finds it. However, IMHO, using this trick should only be necessary as a last resort. Is this a bug? Best regards, Marcel Loose. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake attachment: loose.vcf-- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem with get_filename_component() and CMAKE_CXX_COMPILER when finding Qt4
Any idea on this? Or should I file a bug report? On Mon, Apr 22, 2013 at 3:15 PM, Petr Kmoch petr.km...@gmail.com wrote: If you look at the trace, you'll see the following few lines before the error: C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindQt4.cmake(738): set(CMAKE_REQUIRED_INCLUDES_SAVE ${CMAKE_REQUIRED_INCLUDES} ) C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindQt4.cmake(739): set(CMAKE_REQUIRED_FLAGS_SAVE ${CMAKE_REQUIRED_FLAGS} ) C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindQt4.cmake(741): set(CMAKE_REQUIRED_INCLUDES ${CMAKE_REQUIRED_INCLUDES};${QT_INCLUDE_DIR} ) C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindQt4.cmake(743): CHECK_CXX_SYMBOL_EXISTS(Q_WS_X11 QtCore/qglobal.h Q_WS_X11 ) C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CheckCXXSymbolExists.cmake(41): _CHECK_SYMBOL_EXISTS(${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/CheckSymbolExists.cxx Q_WS_X11 QtCore/qglobal.h Q_WS_X11 ) C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(46): if(Q_WS_X11 MATCHES ^Q_WS_X11$ ) C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(47): set(CMAKE_CONFIGURABLE_FILE_CONTENT /* */\n ) C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(48): set(MACRO_CHECK_SYMBOL_EXISTS_FLAGS ${CMAKE_REQUIRED_FLAGS} ) C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(49): if(CMAKE_REQUIRED_LIBRARIES ) C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(54): else() C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(55): set(CHECK_SYMBOL_EXISTS_LIBS ) C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(57): if(CMAKE_REQUIRED_INCLUDES ) C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(58): set(CMAKE_SYMBOL_EXISTS_INCLUDES -DINCLUDE_DIRECTORIES:STRING=${CMAKE_REQUIRED_INCLUDES} ) C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(63): foreach(FILE QtCore/qglobal.h ) C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(64): set(CMAKE_CONFIGURABLE_FILE_CONTENT ${CMAKE_CONFIGURABLE_FILE_CONTENT}#include ${FILE}\n ) C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(67): set(CMAKE_CONFIGURABLE_FILE_CONTENT ${CMAKE_CONFIGURABLE_FILE_CONTENT}\nint main(int argc, char** argv)\n{\n (void)argv;\n#ifndef Q_WS_X11\n return ((int*)(Q_WS_X11))[argc];\n#else\n (void)argc;\n return 0;\n#endif\n}\n ) C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(70): configure_file(${CMAKE_ROOT}/Modules/CMakeConfigurableFile.in D:/Tmp/cmake/bld/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx @ONLY IMMEDIATE ) C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(73): message(STATUS Looking for Q_WS_X11 ) -- Looking for Q_WS_X11 C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(74): try_compile(Q_WS_X11 ${CMAKE_BINARY_DIR} D:/Tmp/cmake/bld/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx COMPILE_DEFINITIONS ${CMAKE_REQUIRED_DEFINITIONS} CMAKE_FLAGS -DCOMPILE_DEFINITIONS:STRING=${MACRO_CHECK_SYMBOL_EXISTS_FLAGS} ${CHECK_SYMBOL_EXISTS_LIBS} ${CMAKE_SYMBOL_EXISTS_INCLUDES} OUTPUT_VARIABLE OUTPUT ) CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeCXXInformation.cmake:37 (get_filename_component): get_filename_component called with incorrect number of arguments Call Stack (most recent call first): CMakeLists.txt:2 (PROJECT) On Mon, Apr 22, 2013 at 3:05 PM, Rolf Eike Beer e...@sf-mail.de wrote: Am 22.04.2013 14:26, schrieb Petr Kmoch: Hi all. I'm using CMake 2.8.10.2 to do a Visual Studio 2010 64-bit build, and I encountered a weird problem with the CMake configure step failing, with the following output: CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/**CMakeCXXInformation.cmake:37 (get_filename_component): get_filename_component called with incorrect number of arguments Call Stack (most recent call first): CMakeLists.txt:2 (PROJECT) CMAKE_CXX_COMPILER is empty at that point. I managed to pinpoint this to an issue with try_compile in FindQt4. I am attaching a minimal test case as well as output of cmake --trace. The CMakeList is just this: I don't see a try_compile in FindQt4. Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe:
Re: [CMake] Cannot restore timestamp error on Windows
Hi, I read the content of the change in the link you provided, and I have a newbie question: Why not using one timestamp (different filename) per library/binary/project ? Looking forward to having this issue solved in the next official release! Best, Raffi Enficiaud -- View this message in context: http://cmake.3232098.n2.nabble.com/Cannot-restore-timestamp-error-on-Windows-tp7584120p7584273.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindCUDA fails to find libcuda.so
You have a nonstandard install path that will require you to use CUDA_PATH / CUDA_BIN_PATH and CUDA_LIB_PATH. On Mon, Apr 29, 2013 at 10:10 AM, Marcel Loose lo...@astron.nl wrote: Hi, It fails to find CUDA 5.0. See below. $ env | grep CUDA CUDA_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35 CUDA_INC_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35 CUDA_SDK=/cm/shared/apps/cuda50/sdk/5.0.35 CUDA_CACHE_DISABLE=1 CUDA_INSTALL_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35 CUDA_ROOT=/cm/local/apps/cuda50/libs/304.54 $ cat ../CMakeLists.txt cmake_minimum_required(VERSION 2.8) project(CheckCUDALibs) find_package(CUDA) message(STATUS CUDA_LIBRARIES = ${CUDA_LIBRARIES}) $ cmake .. -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Found CUDA: /cm/shared/apps/cuda50/toolkit/5.0.35 (found version 5.0) -- CUDA_LIBRARIES = /cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so -- Configuring done -- Generating done -- Build files have been written to: /home/loose/temp/cmake/cuda/build $ CUDA_LIB_PATH=$CUDA_ROOT/lib cmake .. -- CUDA_LIBRARIES = /cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so;/cm/local/apps/cuda50/libs/304.54/lib64/libcuda.so -- Configuring done -- Generating done -- Build files have been written to: /home/loose/temp/cmake/cuda/build Only when explicitly setting CUDA_LIB_PATH, libcuda.so is found. BTW: On Ubuntu I also need to set CUDA_LIB_PATH, but then to /usr/lib/nvidia-current. Regards, Marcel Loose. On 29/04/13 15:36, Robert Maynard wrote: Can you provide what Cuda version FindCuda is failing to find, and where Cluster Manager is installing the CUDA toolkit and library? On Mon, Apr 29, 2013 at 7:38 AM, Marcel Loose lo...@astron.nl wrote: Hi all, I noticed that FindCUDA.cmake fails to locate libcuda.so on at least two different platforms: Ubuntu 12.10 and CentOS 6.3 using Cluster Manager v5.2. I can persuade FindCUDA.cmake to search for this library by explicitly setting the environment variable CUDA_LIB_PATH, and then it finds it. However, IMHO, using this trick should only be necessary as a last resort. Is this a bug? Best regards, Marcel Loose. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindCUDA fails to find libcuda.so
Hi Robert, I agree that on the CentOS machine the install paths are non-standard. For the Ubuntu system, on the other hand, I have to disagree with that statement. It is a *standard* Ubuntu 12.10 system, so IMHO FindCUDA.cmake should be able to locate libcuda.so on that system. Regards, Marcel Loose. On 29/04/13 16:54, Robert Maynard wrote: You have a nonstandard install path that will require you to use CUDA_PATH / CUDA_BIN_PATH and CUDA_LIB_PATH. On Mon, Apr 29, 2013 at 10:10 AM, Marcel Loose lo...@astron.nl wrote: Hi, It fails to find CUDA 5.0. See below. $ env | grep CUDA CUDA_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35 CUDA_INC_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35 CUDA_SDK=/cm/shared/apps/cuda50/sdk/5.0.35 CUDA_CACHE_DISABLE=1 CUDA_INSTALL_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35 CUDA_ROOT=/cm/local/apps/cuda50/libs/304.54 $ cat ../CMakeLists.txt cmake_minimum_required(VERSION 2.8) project(CheckCUDALibs) find_package(CUDA) message(STATUS CUDA_LIBRARIES = ${CUDA_LIBRARIES}) $ cmake .. -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Found CUDA: /cm/shared/apps/cuda50/toolkit/5.0.35 (found version 5.0) -- CUDA_LIBRARIES = /cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so -- Configuring done -- Generating done -- Build files have been written to: /home/loose/temp/cmake/cuda/build $ CUDA_LIB_PATH=$CUDA_ROOT/lib cmake .. -- CUDA_LIBRARIES = /cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so;/cm/local/apps/cuda50/libs/304.54/lib64/libcuda.so -- Configuring done -- Generating done -- Build files have been written to: /home/loose/temp/cmake/cuda/build Only when explicitly setting CUDA_LIB_PATH, libcuda.so is found. BTW: On Ubuntu I also need to set CUDA_LIB_PATH, but then to /usr/lib/nvidia-current. Regards, Marcel Loose. On 29/04/13 15:36, Robert Maynard wrote: Can you provide what Cuda version FindCuda is failing to find, and where Cluster Manager is installing the CUDA toolkit and library? On Mon, Apr 29, 2013 at 7:38 AM, Marcel Loose lo...@astron.nl wrote: Hi all, I noticed that FindCUDA.cmake fails to locate libcuda.so on at least two different platforms: Ubuntu 12.10 and CentOS 6.3 using Cluster Manager v5.2. I can persuade FindCUDA.cmake to search for this library by explicitly setting the environment variable CUDA_LIB_PATH, and then it finds it. However, IMHO, using this trick should only be necessary as a last resort. Is this a bug? Best regards, Marcel Loose. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake attachment: loose.vcf-- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindCUDA fails to find libcuda.so
I have had no problem with Ubuntu 12.10 and Cuda 5; findCuda is able to find cuda in /usr/lib. Can you run CMake --debug-output output enable and see where findCuda is searching? On Mon, Apr 29, 2013 at 11:52 AM, Marcel Loose lo...@astron.nl wrote: Hi Robert, I agree that on the CentOS machine the install paths are non-standard. For the Ubuntu system, on the other hand, I have to disagree with that statement. It is a *standard* Ubuntu 12.10 system, so IMHO FindCUDA.cmake should be able to locate libcuda.so on that system. Regards, Marcel Loose. On 29/04/13 16:54, Robert Maynard wrote: You have a nonstandard install path that will require you to use CUDA_PATH / CUDA_BIN_PATH and CUDA_LIB_PATH. On Mon, Apr 29, 2013 at 10:10 AM, Marcel Loose lo...@astron.nl wrote: Hi, It fails to find CUDA 5.0. See below. $ env | grep CUDA CUDA_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35 CUDA_INC_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35 CUDA_SDK=/cm/shared/apps/cuda50/sdk/5.0.35 CUDA_CACHE_DISABLE=1 CUDA_INSTALL_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35 CUDA_ROOT=/cm/local/apps/cuda50/libs/304.54 $ cat ../CMakeLists.txt cmake_minimum_required(VERSION 2.8) project(CheckCUDALibs) find_package(CUDA) message(STATUS CUDA_LIBRARIES = ${CUDA_LIBRARIES}) $ cmake .. -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Found CUDA: /cm/shared/apps/cuda50/toolkit/5.0.35 (found version 5.0) -- CUDA_LIBRARIES = /cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so -- Configuring done -- Generating done -- Build files have been written to: /home/loose/temp/cmake/cuda/build $ CUDA_LIB_PATH=$CUDA_ROOT/lib cmake .. -- CUDA_LIBRARIES = /cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so;/cm/local/apps/cuda50/libs/304.54/lib64/libcuda.so -- Configuring done -- Generating done -- Build files have been written to: /home/loose/temp/cmake/cuda/build Only when explicitly setting CUDA_LIB_PATH, libcuda.so is found. BTW: On Ubuntu I also need to set CUDA_LIB_PATH, but then to /usr/lib/nvidia-current. Regards, Marcel Loose. On 29/04/13 15:36, Robert Maynard wrote: Can you provide what Cuda version FindCuda is failing to find, and where Cluster Manager is installing the CUDA toolkit and library? On Mon, Apr 29, 2013 at 7:38 AM, Marcel Loose lo...@astron.nl wrote: Hi all, I noticed that FindCUDA.cmake fails to locate libcuda.so on at least two different platforms: Ubuntu 12.10 and CentOS 6.3 using Cluster Manager v5.2. I can persuade FindCUDA.cmake to search for this library by explicitly setting the environment variable CUDA_LIB_PATH, and then it finds it. However, IMHO, using this trick should only be necessary as a last resort. Is this a bug? Best regards, Marcel Loose. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem with CMAKE_AUTOMOC files not being regenerated or cleaned
On Monday 29 April 2013, Glenn Coombs wrote: I added these lines: set_directory_properties( PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES ${CMAKE_CURRENT_BINARY_DIR}/abc.txt ) # check the location where abc.txt is supposed to be deleted from message(CURRENT_BINARY_DIR: ${CMAKE_CURRENT_BINARY_DIR}) to the end of my CMakeLists.txt and then created abc.txt in the cmake build directory. I can confirm that the abc.txt file was not deleted by a clean solution. I tried this with Visual Studio 2012 and Visual Studio 2008 (both installs are the Express editions) and the results were identical. I don't have Windows here so this is kind of hard for me... Did you do a complete clean or just a clean of some part of the whole project ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cannot restore timestamp error on Windows
On 04/29/2013 10:53 AM, Raffi Enficiaud wrote: I read the content of the change in the link you provided, and I have a newbie question: Why not using one timestamp (different filename) per library/binary/project? The current approach evolved historically. A per-target approach would probably work too but things should be working now anyway. Looking forward to having this issue solved in the next official release! It is already solved in 2.8.11-rc*. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.11-rc3 ready for testing!
Hi, On Friday 19 April 2013, Robert Maynard wrote: The CMake 2.8.11 release candidate continues. This is the last RC unless a critical, must-fix issue is found. You can find the source and binaries here: http://www.cmake.org/files/v2.8/?C=M;O=D what is the current plan, will there be another rc or will the next be the final, and if so, when ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] portable way of linking (external) libs statically/dynamically/for dlopen
Hi. I've always thought one of the main objectives of cmake was being portable, right? So I was looking for a way to let the user (i.e. the person building a project) choose how he wan't to link each external library (i.e. not the ones built as targets by my project), depending on what that lib supports and (when my own code supports it:) dynamically loaded via e.g. dlopen. But it seems that I cannot even tell CMake (in a portable way) that it should use static or dynamic linking for some external lib (not to talk about the core libs like libc or libstdc++). Of course I can work around this any manually search for e.g. .so and .a files... but that woudln't be portable anymore... not to talk about different linkage options per linker... so ideally CMake should (IMHO) take care of all this (for each supported platform/linker). Am I missing something? Or is that just som major deficiency in the portable-part? Cheers, Phil -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] portable way of linking (external) libs statically/dynamically/for dlopen
On Mon, Apr 29, 2013 at 11:13 AM, Philippe Cerfon philc...@gmail.comwrote: Hi. I've always thought one of the main objectives of cmake was being portable, right? So I was looking for a way to let the user (i.e. the person building a project) choose how he wan't to link each external library (i.e. not the ones built as targets by my project), depending on what that lib supports and (when my own code supports it:) dynamically loaded via e.g. dlopen. But it seems that I cannot even tell CMake (in a portable way) that it should use static or dynamic linking for some external lib (not to talk about the core libs like libc or libstdc++). Of course I can work around this any manually search for e.g. .so and .a files... but that woudln't be portable anymore... not to talk about different linkage options per linker... so ideally CMake should (IMHO) take care of all this (for each supported platform/linker). Am I missing something? Or is that just som major deficiency in the portable-part? Static linking of external libraries is just a weird thing to do. Ian -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.11-rc3 ready for testing!
Hi, We found a bug in rc3 and are waiting for the fix to be finalized before we make rc4. You can track the bug by following the 2.8.11-rc3 generator expression error thread. On Mon, Apr 29, 2013 at 2:00 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: Hi, On Friday 19 April 2013, Robert Maynard wrote: The CMake 2.8.11 release candidate continues. This is the last RC unless a critical, must-fix issue is found. You can find the source and binaries here: http://www.cmake.org/files/v2.8/?C=M;O=D what is the current plan, will there be another rc or will the next be the final, and if so, when ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.11-rc3 ready for testing!
On Mon, 2013-04-29 at 14:53 -0400, Robert Maynard wrote: We found a bug in rc3 and are waiting for the fix to be finalized before we make rc4. You can track the bug by following the 2.8.11-rc3 generator expression error thread. I haven't seen any action on that thread since Thursday... the last I heard it seemed Steve and Brad had a fix available. No one is waiting on me (for testing etc.) I hope? Cheers! -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] portable way of linking (external) libs statically/dynamically/for dlopen
On Mon, Apr 29, 2013 at 8:30 PM, Ian Monroe i...@monroe.nu wrote: Static linking of external libraries is just a weird thing to do. And I thought this wasn’t lkml, where it’s perfectly fine that people, instead of answering the question (if they choose to answer at all) tell you your use case would be invalid ;-) Well I'm perfectly aware of the advantages/disadvantages of static linking... but there quite some circumstances where users may prefer it over dynamic linking :) Cheers! -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] portable way of linking (external) libs statically/dynamically/for dlopen
On Monday 29 April 2013, Philippe Cerfon wrote: Hi. I've always thought one of the main objectives of cmake was being portable, right? So I was looking for a way to let the user (i.e. the person building a project) choose how he wan't to link each external library (i.e. not the ones built as targets by my project), depending on what that lib supports and (when my own code supports it:) dynamically loaded via e.g. dlopen. But it seems that I cannot even tell CMake (in a portable way) that it should use static or dynamic linking for some external lib (not to talk about the core libs like libc or libstdc++). Of course I can work around this any manually search for e.g. .so and .a files... but that woudln't be portable anymore... not to talk about different linkage options per linker... so ideally CMake should (IMHO) take care of all this (for each supported platform/linker). Am I missing something? Or is that just som major deficiency in the portable-part? If cmake finds the static version of the library, it should properly use that one. Making cmake find the static version instead of the dynamic version is kind of hard, AFAIK the only way to do this is to give the full filename of the static lib. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cannot restore timestamp error on Windows
Hi Brad, Thank you for your reply. As you pointed out, the problem seems to come from a race condition on the file generate.stamp. Now the operations being atomic, the problem should be solved, in practice. However, I do not fully understand in what extent the atomicity of renaming a file would solve this. The log says: Write the stamp file to a random temporary name and then atomically rename it to the real stamp file. The operations take basically less time; hence the problem should occur less. However: - process 1 is accessing generate.stamp for reading - process 2 is moving some tmpfile to generate.stamp - race The probability of race increases with the number of projects in CMakeList.txt (since they share generate.stamp) and the number of cores used for building (and of course the structure and dependencies among the projects). What if, in .\Source\cmLocalVisualStudio7Generator.cxx, we replace: cmSourceFile* cmLocalVisualStudio7Generator::CreateVCProjBuildRule() { std::string stampName = this-Makefile-GetCurrentOutputDirectory(); stampName += /; stampName += cmake::GetCMakeFilesDirectoryPostSlash(); stampName += generate.stamp; const char* dsprule = this-Makefile-GetRequiredDefinition(CMAKE_COMMAND); by cmSourceFile* cmLocalVisualStudio7Generator::CreateVCProjBuildRule() { std::string stampName = this-Makefile-GetCurrentOutputDirectory(); stampName += /; stampName += cmake::GetCMakeFilesDirectoryPostSlash(); stampName += std::string(this-Makefile-GetProjectName()) + _generate.stamp; const char* dsprule = this-Makefile-GetRequiredDefinition(CMAKE_COMMAND); I do not know the code that much, but I guess Makefile::SetProjectName is called much earlier than cmLocalVisualStudio7Generator::CreateVCProjBuildRule, right? What do you think? Best, Raffi Enficiaud -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: lundi 29 avril 2013 18:56 To: Raffi Enficiaud Cc: cmake@cmake.org Subject: Re: [CMake] Cannot restore timestamp error on Windows On 04/29/2013 10:53 AM, Raffi Enficiaud wrote: I read the content of the change in the link you provided, and I have a newbie question: Why not using one timestamp (different filename) per library/binary/project? The current approach evolved historically. A per-target approach would probably work too but things should be working now anyway. Looking forward to having this issue solved in the next official release! It is already solved in 2.8.11-rc*. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] portable way of linking (external) libs statically/dynamically/for dlopen
For example: https://github.com/commontk/CTK/blob/ac13c32312c9160190b80bd3a03d012782eff40c/Libs/Core/CMake/ctkMacroBFDCheck.cmake#L33-43 Hth Jc On Mon, Apr 29, 2013 at 4:36 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Monday 29 April 2013, Philippe Cerfon wrote: Hi. I've always thought one of the main objectives of cmake was being portable, right? So I was looking for a way to let the user (i.e. the person building a project) choose how he wan't to link each external library (i.e. not the ones built as targets by my project), depending on what that lib supports and (when my own code supports it:) dynamically loaded via e.g. dlopen. But it seems that I cannot even tell CMake (in a portable way) that it should use static or dynamic linking for some external lib (not to talk about the core libs like libc or libstdc++). Of course I can work around this any manually search for e.g. .so and .a files... but that woudln't be portable anymore... not to talk about different linkage options per linker... so ideally CMake should (IMHO) take care of all this (for each supported platform/linker). Am I missing something? Or is that just som major deficiency in the portable-part? If cmake finds the static version of the library, it should properly use that one. Making cmake find the static version instead of the dynamic version is kind of hard, AFAIK the only way to do this is to give the full filename of the static lib. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- +1 919 869 8849 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cannot restore timestamp error on Windows
On 04/29/2013 04:37 PM, Raffi Enficiaud wrote: - process 1 is accessing generate.stamp for reading Nothing ever reads the file. Only its existence and modification time matter. - process 2 is moving some tmpfile to generate.stamp - race The only race was for multiple processes simultaneously deciding they need to create the (currently missing) file and then trying to open the file for write at the same time. That race is gone because replacement is now atomic. stampName += std::string(this-Makefile-GetProjectName()) CMake has a different meaning for project than .vcxproj so this will still be the same name for all targets in a directory. Each .vcxproj file corresponds to what CMake calls a target. In order to use a different stamp file for each .vcxproj file then the custom command produced by CreateVCProjBuildRule would not be able to be re-used across multiple targets. Instead each generator would have to hand-code the custom command for its own .vcxproj file. While possible it is a lot of work and this bug has already been solved. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't get CTEST_CUSTOM_ERROR_MATCH to work with CTest launchers
For reference I have opened a new issue: http://public.kitware.com/Bug/view.php?id=14121 Nils On 04/25/2013 10:00 PM, Nils Gladitz wrote: I was able to reproduce the problem with Ninja on Ubuntu and CMake 2.8.11-rc2. I set up a test project for which I set CTEST_CUSTOM_ERROR_MATCH to FooBar. It has three custom commands with different outputs and exit codes: CustomCommand1: this is a FooBar message (exit success) CustomCommand2: this is a fatal error (exit failure) CustomCommand3: this is a FooBar fatal error (exit failure) These are the results that I got (numbers in braces indicate which custom commands produce output visible on CDash): Ninja (Launchers enabled): 0 Build Errors Ninja (Launchers disabled): 4 Build Errors (1, 2, 3) Unix Makefiles (Launchers enabled): 2 Build Errors (2, 3) Unix Makefiles (Launchers disabled): 4 Build Errors (1, 2, 3) For Unix Makefiles this seems to work better though not quite as I expected either. (I expected CustomCommand1 to trigger an error even though the exit code is 0 due to it having FooBar in the output). But if this is by design it would be nice to have at least the commands with failed exit status show up with Ninja like they do with Makefiles. Hope this helps to diagnose the problem. Nils On 04/25/2013 07:04 PM, Jean-Christophe Fillion-Robin wrote: This is probably caused by commit 965358fcf [1] Can the problem be reproduced using Ninja on Unix platform ? [1] https://github.com/Kitware/CMake/commit/965358fcf64cf1a3693bcdd66f723729e0614ef6 On Thu, Apr 25, 2013 at 12:41 PM, Nils Gladitz glad...@sci-vis.de mailto:glad...@sci-vis.de wrote: Hey Jean-Christophe, I currently use CMake 2.8.11-rc3 with the Ninja generator on windows. Nils On 25.04.2013 17 tel:25.04.2013%2017:30, Jean-Christophe Fillion-Robin wrote: Hi Nils, Since CTEST_USE_LAUNCHERS is ignored when used with generator different from Make or Ninja [1], it seems strange that it impacts your windows build. Which generator are you using ? Hth Jc [1] https://github.com/Kitware/CMake/blob/master/Modules/CTestUseLaunchers.cmake#L38-40 On Thu, Apr 25, 2013 at 4:44 AM, Nils Gladitz glad...@sci-vis.de mailto:glad...@sci-vis.de wrote: One list entry in my CTEST_CUSTOM_ERROR_MATCH is FAILED: (in my CTestCustom.cmake.in http://CTestCustom.cmake.in which is used to generate CTestCustom.cmake in the build directory). With CTEST_USE_LAUNCHERS enabled this does not seem to match errors from custom commands e.g.: FAILED: cmd.exe /c [...] On my CDash installation I see 0 build errors. When I disable CTEST_USE_LAUNCHERS the error shows up on the dashboard and the FAILED: line is highlighted indicating that a match has been made. Is this by design (e.g. not implemented for launchers) or may I be missing something? Is there e.g. extra work required for CTEST_CUSTOM_ERROR_MATCH to reach the launcher? Nils -- Nils Gladitz, B.Sc. DICOM, Konnektivität und Entwicklung Scivis wissenschaftliche Bildverarbeitung GmbH Bertha-von-Suttner-Str. 5 D-37085 Göttingen GERMANY Handelsregister Nr. / Trade Register No. B3100 Göttingen Geschäftsführer / Managing Directors Dr. Gernot Ebel, Dr. Uwe Engeland Tel: 0049 (0)551 634181-28 E-Mail: glad...@scivis.de mailto:glad...@scivis.de Web: www.scivis.de http://www.scivis.de -- Powered by www.kitware.com http://www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- +1 919 869 8849 tel:%2B1%20919%20869%208849 -- +1 919 869 8849 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] 'AUTOMOC' feature skips sources of executable targets?
Have a look at my post on StackOverflow http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips-sources-of-executable-targets for details. http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips-sources-of-executable-targets -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 'AUTOMOC' feature skips sources of executable targets?
On Monday 29 April 2013, Haroogan wrote: Have a look at my post on StackOverflow http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips-so urces-of-executable-targets for details. http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips-so urces-of-executable-targets can you please create a small testcase and post it here, or create an entry on http://public.kitware.com/Bug and attach it there ? It should work. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] portable way of linking (external) libs statically/dynamically/for dlopen
On Mon, Apr 29, 2013 at 10:36 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: If cmake finds the static version of the library, it should properly use that one. I thought it would use the shared one per default? Making cmake find the static version instead of the dynamic version is kind of hard, AFAIK the only way to do this is to give the full filename of the static lib. In other words: not portable. :( -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] portable way of linking (external) libs statically/dynamically/for dlopen
On Mon, Apr 29, 2013 at 10:40 PM, Jean-Christophe Fillion-Robin jchris.filli...@kitware.com wrote: For example: https://github.com/commontk/CTK/blob/ac13c32312c9160190b80bd3a03d012782eff40c/Libs/Core/CMake/ctkMacroBFDCheck.cmake#L33-43 I'm not sure whether I understand this correctly, or whether it is what I want ;) You still seem to hardcode the static library name (= not portable) -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 'AUTOMOC' feature skips sources of executable targets?
On 29-Apr-13 23:27, Alexander Neundorf wrote: On Monday 29 April 2013, Haroogan wrote: Have a look at my post on StackOverflow http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips-so urces-of-executable-targets for details. http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips-so urces-of-executable-targets can you please create a small testcase and post it here, or create an entry on http://public.kitware.com/Bug and attach it there ? It should work. Alex Just tried a simple test case, involving bare executable, and that indeed works. As I said in the real project, this executable links with several shared libraries. How can that affect the fact that 'AUTOMOC' should be carried out for executable's sources? Nothing else changes, I promise. Unfortunately, it would be very cumbersome to create an example since we depend on 3rd party framework, which has to be built and properly incorporated into the project, and I wouldn't impose such a burden on you. What could be the potential problem? -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 'AUTOMOC' feature skips sources of executable targets?
On Monday 29 April 2013, Haroogan wrote: On 29-Apr-13 23:27, Alexander Neundorf wrote: On Monday 29 April 2013, Haroogan wrote: Have a look at my post on StackOverflow http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips -so urces-of-executable-targets for details. http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips -so urces-of-executable-targets can you please create a small testcase and post it here, or create an entry on http://public.kitware.com/Bug and attach it there ? It should work. Alex Just tried a simple test case, involving bare executable, and that indeed works. As I said in the real project, this executable links with several shared libraries. How can that affect the fact that 'AUTOMOC' should be carried out for executable's sources? Nothing else changes, I promise. Unfortunately, it would be very cumbersome to create an example since we depend on 3rd party framework, which has to be built and properly incorporated into the project, and I wouldn't impose such a burden on you. What could be the potential problem? Not much. The cmake variable QT_VERSION_MAJOR must be set. That's more or less the only thing I can think of. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 'AUTOMOC' feature skips sources of executable targets?
On 29-Apr-13 23:27, Alexander Neundorf wrote: On Monday 29 April 2013, Haroogan wrote: Have a look at my post on StackOverflow http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips-so urces-of-executable-targets for details. http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips-so urces-of-executable-targets can you please create a small testcase and post it here, or create an entry on http://public.kitware.com/Bug and attach it there ? It should work. Alex I've found the cause, and I think that's very confusing behavior. I'll try to do my best explaining it. Let's begin with top 'CMakeLists.txt': ... set(CMAKE_INCLUDE_CURRENT_DIR ON) set(CMAKE_AUTOMOC ON) ... # NOTE: Order matters (the most independent ones go first) # because some libraries expose variables through cache (see below). add_subdirectory(components/B) add_subdirectory(components/A) add_subdirectory(components/Executable) So imagine that we have the 'FindMyPrecious.cmake' custom CMake module to locate 3rd party framework MyPrecious: find_package(Qt4 4.7.4 COMPONENTS QtCore QtGui QtXml REQUIRED) find_path(MyPrecious_INCLUDE_DIR...) find_library(MyPrecious_LIBRARY_DEBUG...) find_library(MyPrecious_LIBRARY_RELEASE...) set(QT_DEFINITIONS ${QT_DEFINITIONS} -DQT_CORE_LIB -DQT_GUI_LIB -DQT_XML_LIB) if (CMAKE_BUILD_TYPE MATCHES [Dd][Ee][Bb][Uu][Gg]) set(QT_DEFINITIONS ${QT_DEFINITIONS} -DQT_DEBUG) else () set(QT_DEFINITIONS ${QT_DEFINITIONS} -DQT_NO_DEBUG) endif () set(MyPrecious_DEFINITIONS ${QT_DEFINITIONS}) set(MyPrecious_INCLUDE_DIRS ${MyPrecious_INCLUDE_DIR} ${QT_INCLUDE_DIR} ${QT_QTCORE_INCLUDE_DIR} ${QT_QTGUI_INCLUDE_DIR} ${QT_QTXML_INCLUDE_DIR}) set(MyPrecious_LIBRARY debug ${MyPrecious_LIBRARY_DEBUG} optimized ${MyPrecious_LIBRARY_RELEASE}) set(MyPrecious_LIBRARIES ${MyPrecious_LIBRARY} ${QT_QTCORE_LIBRARY} ${QT_QTGUI_LIBRARY} ${QT_QTXML_LIBRARY}) include(FindPackageHandleStandardArgs) find_package_handle_standard_args(MyPrecious DEFAULT_MSG MyPrecious_INCLUDE_DIR MyPrecious_LIBRARY MyPrecious_LIBRARY_DEBUG MyPrecious_LIBRARY_RELEASE) mark_as_advanced(MyPrecious_INCLUDE_DIR MyPrecious_LIBRARY MyPrecious_LIBRARY_DEBUG MyPrecious_LIBRARY_RELEASE) Everything is cool so far. One thing to note is that since MyPrecious depends on Qt we are employing transitive dependency strategy as recommended on CMake Wiki. Now let's move to the shared library A (from our project) which depends on MyPrecious: cmake_minimum_required(VERSION 2.8.10) project(A C CXX) find_package(MyPrecious REQUIRED) file(GLOB CPP_FILES sources/*.cpp) add_definitions(${MyPrecious_DEFINITIONS}) include_directories(${B_INCLUDE_DIRS}# some other library B (in this case header-only); B exposed includes with the same strategy ${MyPrecious_INCLUDE_DIRS}) add_library(${PROJECT_NAME} SHARED ${CPP_FILES}) target_link_libraries(${PROJECT_NAME} ${MyPrecious_LIBRARIES}) # Pay attention here, we want to make definitions and includes visible (through cache) to the executable since it is going to link against this library A set(${PROJECT_NAME}_DEFINITIONS ${MyPrecious_DEFINITIONS} CACHE INTERNAL ${PROJECT_NAME}: Definitions FORCE) set(${PROJECT_NAME}_INCLUDE_DIRS ${PROJECT_SOURCE_DIR}/includes ${B_INCLUDE_DIRS}# some other library B (in this case header-only);B exposed includes with the same strategy ${MyPrecious_INCLUDE_DIRS} CACHE INTERNAL ${PROJECT_NAME}: Include Directories FORCE) Finally, let's move to the executable project: cmake_minimum_required(VERSION 2.8.10) project(Executable C CXX) # --- # ATTENTION: Theoretically, I don't have to add the line below. # --- # find_package(MyPrecious REQUIRED) # --- # Furthermore, as I said if I use plain old 'qt4_wrap_cpp', I don't add it and everything builds fine indeed. # However, now when using 'AUTOMOC' approach it turns out that without this line CMake does not create 'AUTOMOC' target for sources of this project. # The above line simply finds MyPrecious, which you can see is not even used any further. I.e. all the definitions and includes of Qt, MyPrecious, B, and A are # obtained transitively through the cache variables (see below/above). However, we know that the above line finds Qt too. # So the only logical thing that comes to my mind is that CMakes 'AUTOMOC' feature works only when one explicitly or implicitly (like in this case) finds Qt (with `find_package`) # for the project which is desired to be 'AUTOMOC'ed. I
Re: [CMake] Cannot restore timestamp error on Windows
The only race was for multiple processes simultaneously deciding they need to create the (currently missing) file and then trying to open the file for write at the same time. To what I see on the logs, this is not what I observe: build 26-avr.-2013 13:11:12 CMake does not need to re-run because XXX\tmp\src\\CMakeFiles\generate.stamp is up-to-date. build 26-avr.-2013 13:11:12 Building Custom Rule CCC/CMakeLists.txt build 26-avr.-2013 13:11:12 Building Custom Rule CCC/CMakeLists.txt build 26-avr.-2013 13:11:12 Building Custom Rule CCC/CMakeLists.txt build 26-avr.-2013 13:11:12 CMake does not need to re-run because XXX\tmp\src\\CMakeFiles\generate.stamp is up-to-date. then build 26-avr.-2013 13:11:24 Building Custom Rule CCC/CMakeLists.txt build 26-avr.-2013 13:11:24 CUSTOMBUILD : CMake error : Cannot restore timestamp XXX\tmp\src\\CMakeFiles\generate.stamp [XXX\tmp\src\\SSS.vcxproj] The file XXX\tmp\src\\CMakeFiles\generate.stamp already existed long before the error, and many projects were built between. But if by missing you are saying that it is missing because moved to another filename (I am a bit ignorant of how it works), then we still have a race condition. CMake has a different meaning for project than .vcxproj so this will still be the same name for all targets in a directory. Each .vcxproj file corresponds to what CMake calls a target. Indeed, sorry for that mistake. That race is gone because replacement is now atomic This is true for unices, but does not seem to be true on Windows. There is a fallback that tries to move the file 5 times before triggering an error. This is not atomic. In order to use a different stamp file for each .vcxproj file then the custom command produced by CreateVCProjBuildRule would not be able to be re-used across multiple targets. Instead each generator would have to hand-code the custom command for its own .vcxproj file. While possible it is a lot of work and this bug has already been solved. True, and more true now I have a closer look at the code. I do not understand why it was so (historically), and not understanding that does not help me to provide you a patch. For instance, in cmLocalVisualStudio10Generator::Generate(), all vcxproj are generated, and then one unique timestamp file is written, hence for the current CMakeLists.txt. If I understand well, this is the only location (VC10) where the timestamp is written/made dirty. cmLocalVisualStudio7Generator::CreateVCProjBuildRule() adds a rule for checking the timestamp, but I do not understand why this is not a per-target custom build rule in cmLocalVisualStudio7Generator::AddCMakeListsRules() (this could easily be done in cmLocalVisualStudio10Generator::Generate()), nor to what entity the this-Makefile-AddCustomCommandToOutput (in cmLocalVisualStudio7Generator::CreateVCProjBuildRule() ) refers to. But if we have something like: void cmLocalVisualStudio7Generator::AddCMakeListsRules() { cmTargets tgts = this-Makefile-GetTargets(); // Create the regeneration custom rule. if(!this-Makefile-IsOn(CMAKE_SUPPRESS_REGENERATION)) { // HERE: just returning the files that should be included if(cmSourceFile* sf = this-Get_CMAKELISTFILENAME()) { // Add the rule to targets that need it. for(cmTargets::iterator l = tgts.begin(); l != tgts.end(); ++l) { if(l-first != CMAKE_CHECK_BUILD_SYSTEM_TARGET) { l-second.AddSourceFile(sf); // HERE adding the custom build rule checking the timestamps l-ADD_CUSTOM_BUILD_RULE_WITH_STAMPS(); } this should be closer to what I thought initially. For an automatic build daemon, I think setting CMAKE_SUPPRESS_REGENERATION should be sufficient workaround (until the next true release with the proposed workaround). Best, Raffi Enficiaud -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] portable way of linking (external) libs statically/dynamically/for dlopen
hard coded names aren't so bad, since they can be composed of dynamic peices... lib${CMAKE_LIBRARY_SUFFIX}/${CMAKE_SHARED_LIBRARY_PREFIX}c${CMAKE_SHARED_LIBRARY_SUFFIX} or lib${CMAKE_LIBRARY_SUFFIX}/${CMAKE_STATIC_LIBRARY_PREFIX}c${CMAKE_STATIC_LIBRARY_SUFFIX} to choose lib[64]/libc.so or lib[64]/libc.a (or it would generate c.dll/c.lib for windows type compilers) But, although you can generate portable projects that target lots of platforms, the scripts still have to have things like if( WIN32 ) if( UNIX ) etc... On Mon, Apr 29, 2013 at 2:38 PM, Philippe Cerfon philc...@gmail.com wrote: On Mon, Apr 29, 2013 at 10:40 PM, Jean-Christophe Fillion-Robin jchris.filli...@kitware.com wrote: For example: https://github.com/commontk/CTK/blob/ac13c32312c9160190b80bd3a03d012782eff40c/Libs/Core/CMake/ctkMacroBFDCheck.cmake#L33-43 I'm not sure whether I understand this correctly, or whether it is what I want ;) You still seem to hardcode the static library name (= not portable) -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] portable way of linking (external) libs statically/dynamically/for dlopen
On Tue, Apr 30, 2013 at 1:54 AM, J Decker d3c...@gmail.com wrote: lib${CMAKE_LIBRARY_SUFFIX}/${CMAKE_SHARED_LIBRARY_PREFIX}c${CMAKE_SHARED_LIBRARY_SUFFIX} or lib${CMAKE_LIBRARY_SUFFIX}/${CMAKE_STATIC_LIBRARY_PREFIX}c${CMAKE_STATIC_LIBRARY_SUFFIX} to choose lib[64]/libc.so or lib[64]/libc.a (or it would generate c.dll/c.lib for windows type compilers) But, although you can generate portable projects that target lots of platforms, the scripts still have to have things like if( WIN32 ) if( UNIX ) etc... Well exactly this is what I don't wan to do as it's not portable... _I_ (the developer) need to take care on any possible platorm, it's library naming conventions and possibly also on any compiler/linker suite I want to support... If the responsibility for this falls back to me, I can also build via shell script (more or less). What I'd like to have is: 1) My CMakeLists checks for all dependencies (e.g. lib foo) using the CMakes functions for that. These functions should tell me which versions were found (i.e. static or shared). 2) Depending on (1) I set CMake options cache with reasonable defaults (i.e. in most cases this will be link lib foo dynamic) for each lib foo. For some I might even offer to use dlopen(), depending on whether my sources support this. 3) The user can then chance that settings per lib in the cache as he likes. 4) When I say target_link_library... I want to set some flag (static vs. shared) depending on what was chosen in (3) (or not link at all in case of dlopen()), Everything else, platform naming conventions, compiler/linker options, should happen automatically (for all supported platforms + compilter/linker suites)... that would be portability. Cheers! -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, master, updated. v2.8.10.2-1010-g2ba65cc
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 2ba65cc9d904b634120b1b56eabd046aad33ac75 (commit) from c80594ba1274c3dc44c3f2efd70bd5c3d9066bf5 (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=2ba65cc9d904b634120b1b56eabd046aad33ac75 commit 2ba65cc9d904b634120b1b56eabd046aad33ac75 Author: Kitware Robot kwro...@kitware.com AuthorDate: Tue Apr 30 00:01:05 2013 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Tue Apr 30 00:01:05 2013 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 7133dc9..2293000 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 10) -set(CMake_VERSION_TWEAK 20130429) +set(CMake_VERSION_TWEAK 20130430) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits