[cmake-developers] [CMake 0012539]: Expect CTestConfig.cmake in either the build or source directory
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12539 == Reported By:Jean-Christophe Fillion-Robin Assigned To: == Project:CMake Issue ID: 12539 Category: (No Category) Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2011-10-26 04:06 EDT Last Modified: 2011-10-26 04:06 EDT == Summary:Expect CTestConfig.cmake in either the build or source directory Description: Would it be possible to include the following topic in the release: https://github.com/jcfr/CMake/tree/check-ctestconfig-in-builddir The change is documented and tests have been added: Expect CTestConfig.cmake in either the build or source directory … Provide the ability to configure CTest with setting different from the one available in the source tree by checking first if CTestConfig.cmake exists in the build tree first. The motivation is to allow build system checking out external project to test and/or package them and submit the associated results to a different dashboard than the one specified (or not) in the source of the external project. For example, the build system of Slicer can checkout, build, test and package what I will call extension. These extensions can be developed by third party who can test and submit to their own dashboard / project. When checkout by Slicer build system, the default dashboard can be now overwritten by adding a custom CTestConfig.cmake to the build directory. And if not overwritten, it would avoid to create CTestConfig.cmake within the source checkout of the extension. == Issue History Date ModifiedUsername FieldChange == 2011-10-26 04:06 Jean-Christophe Fillion-RobinNew Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012540]: Error configuring project using Intel Fortran with Visual Studio generator
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12540 == Reported By:Martin Apel Assigned To: == Project:CMake Issue ID: 12540 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2011-10-26 04:47 EDT Last Modified: 2011-10-26 04:47 EDT == Summary:Error configuring project using Intel Fortran with Visual Studio generator Description: We have a project setup, which uses C, C++ and Fortran. Additionally we have defined custom build types with compile flags for these build types. Up to 2.8.6-rc2 this project could be configured using the Visual Studio 9 2008 generator without problems. Since 2.8.6-rc3 (and also the final 2.8.6 release) the configuration step generates errors related to our custom build types: -- Check for working Fortran compiler using: Visual Studio 9 2008 CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_Fortran_FLAGS_NOOPT CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_EXE_LINKER_FLAGS_NOOPT CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_Fortran_FLAGS_DEBUGWARN CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_EXE_LINKER_FLAGS_DEBUGWARN The suffixes DEBUGWARN and NOOPT stem from our custom build types. Unfortunately I have not succeeded in creating a small sample project, which reproduces the problem. Performing the same configuration with other generators such as NMake on Windows or Make on Linux succeeds without problems. Additional Information: I have attached to trace files generated by cmake-2.8.6-rc2 and cmake-2.8.6-rc3 when calling cmake -G Visual Studio 9 2008 --trace source dir == Issue History Date ModifiedUsername FieldChange == 2011-10-26 04:47 Martin ApelNew Issue 2011-10-26 04:47 Martin ApelFile Added: traces.tar.gz == -- 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] Merging cmake-link-interface-libraries into master?
On 10/25/2011 5:11 PM, Alexander Neundorf wrote: On Tuesday 25 October 2011, Stephen Kelly wrote: ... I think I read somewhere that next gets re-branched from master periodically. How often does that happen? Usually every Tuesday. The Tuesday meetings are when we consider merging topics into master. The 'next' branch has never been rewritten. However, we have once reverted all changes on it back to match master, rebased all the remaining topics onto master, and merged them again to 'next'. This gave us a clean breaking point in the history of 'next' so we can exclude old history from our view without actually rewriting it. -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] Some documentation patches
2011/10/24 Brad King brad.k...@kitware.com: On 10/24/2011 4:53 AM, Nicolas Desprès wrote: Ok. Here the real change applied on this file (except the remove of the trailing white-space). It fixes some doxygen warnings: diff --git a/Source/kwsys/SystemTools.hxx.in b/Source/kwsys/SystemTools.hxx.in I committed this separately, thanks. Now the branch no longer touch this file. I merged the branch to 'next' for testing. I am thinking that maybe it would be nice to have a pre-commit hook that warn the developer not to modify some part of the tree. Good idea. We already have some local hooks: http://www.cmake.org/Wiki/Git/Hooks They use a common hooks branch shared in many Kitware projects. The common hooks support chaining to per-project hooks in the source tree. I added a 'local-hooks' topic to chain hooks for CMake and then added a check for this: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b2d6adf1 Once merged to master then new work based on that version or later will get this check if the local hooks are installed. Works perfectly! Thanks! git config hooks.chain-pre-commit Utilities/Git/pre-commit -- Nicolas Desprès -- 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] local pre-commit hook (was: Some documentation patches)
On 10/26/2011 11:07 AM, Nicolas Desprès wrote: 2011/10/24 Brad Kingbrad.k...@kitware.com: Once merged to master then new work based on that version or later will get this check if the local hooks are installed. Works perfectly! Thanks! git config hooks.chain-pre-commit Utilities/Git/pre-commit You shouldn't need to do that if you have the latest hooks branch in your .git/hooks directory. It will load the chain rule out of the .hooks-config.bash at the top of the source tree. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] Tell people that link_directories() is not what they are searching for
From 7c31000a1e52d3855f6f5162645a126daafd5105 Mon Sep 17 00:00:00 2001 From: Rolf Eike Beer eike-ker...@sf-tec.de Date: Wed, 26 Oct 2011 20:43:21 +0200 Subject: [PATCH] Tell people that link_directories() is not what they are searching for Judging from the questions I see on the #cmake IRC channel this is one of the most common pitfalls for people coming from other build systems, especially plain Makefiles. Finally put this into the documentation to stop people getting fooled into using this. --- Source/cmLinkDirectoriesCommand.h |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/Source/cmLinkDirectoriesCommand.h b/Source/cmLinkDirectoriesCommand.h index e5ff4f0..f40dd25 100644 --- a/Source/cmLinkDirectoriesCommand.h +++ b/Source/cmLinkDirectoriesCommand.h @@ -65,7 +65,11 @@ public: For historical reasons, relative paths given to this command are passed to the linker unchanged (unlike many CMake commands which interpret them relative to the - current source directory). + current source directory).\n + Please note that this command is usually not what you are searching + for. In most cases you do not need to explicitely specify the linker + search path. Just pass the absolute path of your libraries to + target_link_libraries() and let CMake handle the details. ; } -- 1.7.3.2 -- 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] [PATCH] Tell people that link_directories() is not what they are searching for
On 10/26/2011 2:47 PM, Rolf Eike Beer wrote: From 7c31000a1e52d3855f6f5162645a126daafd5105 Mon Sep 17 00:00:00 2001 From: Rolf Eike Beereike-ker...@sf-tec.de Date: Wed, 26 Oct 2011 20:43:21 +0200 Subject: [PATCH] Tell people that link_directories() is not what they are searching for What command are you using to generate this patch? It does not apply correctly with git am for me. I end up manually removing the From: Date: and Subject: from the commit message. + Please note that this command is usually not what you are searching + for. In most cases you do not need to explicitely specify the linker + search path. Just pass the absolute path of your libraries to + target_link_libraries() and let CMake handle the details. Good idea. Perhaps this wording: Note that this command is rarely necessary. Library locations returned by find_package() and find_library() are absolute paths. Pass these absolute library file paths directly to the target_link_libraries() command. CMake will ensure the linker finds them. ? -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] [PATCH] Tell people that link_directories() is not what they are searching for
Am Mittwoch 26 Oktober 2011, 15:14:22 schrieb Brad King: On 10/26/2011 2:47 PM, Rolf Eike Beer wrote: From 7c31000a1e52d3855f6f5162645a126daafd5105 Mon Sep 17 00:00:00 2001 From: Rolf Eike Beereike-ker...@sf-tec.de Date: Wed, 26 Oct 2011 20:43:21 +0200 Subject: [PATCH] Tell people that link_directories() is not what they are searching for What command are you using to generate this patch? It does not apply correctly with git am for me. I end up manually removing the From: Date: and Subject: from the commit message. git format-patch -1 I copied that into the mail then. Maybe git am got confused when you saved the email because those headers were there from both git and the email program? No idea. + Please note that this command is usually not what you are searching + for. In most cases you do not need to explicitely specify the linker + search path. Just pass the absolute path of your libraries to + target_link_libraries() and let CMake handle the details. Good idea. Perhaps this wording: Note that this command is rarely necessary. Library locations returned by find_package() and find_library() are absolute paths. Pass these absolute library file paths directly to the target_link_libraries() command. CMake will ensure the linker finds them. I wouldn't object that either. Just wanting to get rid of this questions ;) Btw.: the HTML help on the webpage is still from 2.8.6. Eike -- 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] [PATCH] Tell people that link_directories() is not what they are searching for
Am Mittwoch 26 Oktober 2011, 15:23:53 schrieb David Cole: On Wed, Oct 26, 2011 at 3:17 PM, Rolf Eike Beer e...@sf-mail.de wrote: Btw.: the HTML help on the webpage is still from 2.8.6. 2.8.6 is the most recent official release. What version do you expect to see on the webpage? Err, sorry, screwup in brain. 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] [PATCH] Tell people that link_directories() is not what they are searching for
Am Mittwoch 26 Oktober 2011, 15:33:36 schrieb Brad King: On 10/26/2011 3:17 PM, Rolf Eike Beer wrote: Am Mittwoch 26 Oktober 2011, 15:14:22 schrieb Brad King: Note that this command is rarely necessary. Library locations returned by find_package() and find_library() are absolute paths. Pass these absolute library file paths directly to the target_link_libraries() command. CMake will ensure the linker finds them. I wouldn't object that either. Just wanting to get rid of this questions ;) Please re-submit the patch with the above wording and using one of the corrected methods described above. Attached. EikeFrom 2bb1131e9f01b1b395916a5ba62951f325e73fd0 Mon Sep 17 00:00:00 2001 From: Rolf Eike Beer eike-ker...@sf-tec.de Date: Wed, 26 Oct 2011 20:43:21 +0200 Subject: [PATCH] Tell people that link_directories() is not what they are searching for Judging from the questions I see on the #cmake IRC channel this is one of the most common pitfalls for people coming from other build systems, especially plain Makefiles. Finally put this into the documentation to stop people getting fooled into using this. Text by Brad King. --- Source/cmLinkDirectoriesCommand.h |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/Source/cmLinkDirectoriesCommand.h b/Source/cmLinkDirectoriesCommand.h index e5ff4f0..aa13589 100644 --- a/Source/cmLinkDirectoriesCommand.h +++ b/Source/cmLinkDirectoriesCommand.h @@ -65,7 +65,12 @@ public: For historical reasons, relative paths given to this command are passed to the linker unchanged (unlike many CMake commands which interpret them relative to the - current source directory). + current source directory).\n + Note that this command is rarely necessary. Library locations + returned by find_package() and find_library() are absolute paths. + Pass these absolute library file paths directly to the + target_link_libraries() command. CMake will ensure the linker finds + them. ; } -- 1.7.3.2 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
[cmake-developers] [CMake 0012541]: Missing option to pass flags to moc for AUTOMOC targets
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12541 == Reported By:Jason Haslam Assigned To: == Project:CMake Issue ID: 12541 Category: CMake Reproducibility:N/A Severity: minor Priority: normal Status: new == Date Submitted: 2011-10-26 16:49 EDT Last Modified: 2011-10-26 16:49 EDT == Summary:Missing option to pass flags to moc for AUTOMOC targets Description: The qt4_wrap_cpp() macro has an optional OPTIONS flag to allow passing extra flags to moc. The new AUTOMOC property seems to be missing equivalent functionality. Suggest adding a new AUTOMOC_OPTIONS or AUTOMOC_FLAGS (or similar) property for this purpose. == Issue History Date ModifiedUsername FieldChange == 2011-10-26 16:49 Jason Haslam 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] Bug fix requests for the *next* release of CMake...
Reminder: Please make your requests for bug fixes for CMake 2.8.7 by the end of the day, this Friday, October 28. It will be nice to have as complete a picture as possible so we can plan the next 6 weeks effectively. Thanks, David On Fri, Oct 21, 2011 at 2:20 PM, David Cole david.c...@kitware.com wrote: As an esteemed colleague has pointed out, those with reporter level account in Mantis may not edit bugs other than their own directly. So. if you are in that boat, but would like to vote for a bug fix to be considered for 2.8.7, please reply to this thread, and just list the bug number, or a URL linking to its bug tracker page. I will follow the replies to this thread and add those bugs to the roadmap as they roll in. Thanks, David C. On Fri, Oct 21, 2011 at 12:19 PM, David Cole david.c...@kitware.com wrote: Hi all, *NO* replies requested. Different technique this time. Please edit the bug tracker directly. (Unless you have problems with the bug tracker: if so, please feel free to reply here with your suggestions.) We are planning for CMake 2.8.7, aiming for a December release. We're targeting Dec. 28, 2011 for releasing it, and in order to make that happen we'll have to do an rc1 by Dec. 7th or so... about 7 weeks from now. If you have a particular issue that you think should be fixed for inclusion in 2.8.7, please put it on the roadmap yourself by the end of next week, Fri. Oct. 28th. To do so, edit the bug at http://public.kitware.com/Bug and set the Target Version field to CMake 2.8.7 - that will make it appear on the roadmap page ( http://www.cmake.org/Bug/roadmap_page.php?version_id=89 ). Also: add a note saying why it's important to you, or even add a patch that fixes and documents and tests it if you're able to. Ideally, each issue will be discussed as needed on the mailing list to come to any consensus about what should be done to fix it, and then the entry in the bug tracker may be used to keep it on the radar screen, and to track activity related to it. Patches are *always* welcome. Patches that include testing of any new features, or tests that prove a bug is really fixed on the dashboards are better: a patch with testing is strongly preferred over a patch with no testing. Also, if you are *adding* code, then you also probably need to add *tests* of that code, so that the coverage percentage stays as is or rises. Please discuss issues here on the mailing list as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed for 2.8.7 -- we will be looking at activity both on the mailing list and in the bug tracker to help prioritize the bug fixes for the next couple months. Thanks, David Cole Kitware, Inc. P.S. - as a nice summary of what we accomplished in the CMake 2.8.6 release, including contributions from 27 individuals around the world, see here: http://public.kitware.com/Bug/changelog_page.php?version_id=87 -- it currently lists 43 issues that we resolved: nice job, everybody! (Many of those were specifically addressed because somebody brought it up in response to my similar email from just after 2.8.5... Don't be shy!) -- 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
