Re: [CMake] [cmake-developers] Bug fix requests for the *next* release of CMake...
http://public.kitware.com/Bug/view.php?id=8996 On Wed, Nov 7, 2012 at 8:40 PM, David Cole david.c...@kitware.com wrote: Hi all, Replies requested. Short replies only. Read on. Just a short reply with bug numbers or links to the bugs is all we need here. Example one-line reply: http://public.kitware.com/Bug/view.php?id=13571 Please move specific discussions into the bugs themselves or start a new thread to talk about it... Replies on this thread should just be a collector for bug numbers. We are aiming for approximately quarterly releases from now on, scheduling them every 3 to 4 months. The next release of CMake will likely be version 2.8.11, scheduled to have an rc1 release candidate on Wed. January 9, 2013 -- just 9 weeks from today. If you have a particular issue that you think should be fixed for inclusion in 2.8.11, please bring it up within the next two weeks. 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 an entry in the bug tracker may be used to keep it on the radar screen, and to track activity related to it. You can see what's already on the roadmap for this release here: http://public.kitware.com/Bug/roadmap_page.php?version_id=103 Patches are always welcome. Patches that include testing of any new features, or tests that prove a bug is really fixed on the dashboards, (basically any patch with testing) is 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 as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed -- we will be looking at the mailing list and activity in the bug tracker to help prioritize the bug fixes that will occur in the near future. Thanks, David Cole Kitware, Inc. P.S. - as a nice summary of what we accomplished in the CMake 2.8.10 release, see here: http://public.kitware.com/Bug/changelog_page.php?version_id=100 -- it currently lists 58 issues that we resolved: nice job, everybody! (Many of those were specifically addressed because somebody asked for it right here on the mailing list... 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 -- 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-developers] Bug fix requests for the *next* release of CMake...
Am Dienstag 29 März 2011, 19:56:03 schrieb David Cole: Hi all, Now that we have released CMake 2.8.4, *now* would be a great time to prioritize bug fixes for the next release of CMake. Replies requested. Read on. *Just a short reply with bug numbers* or links to the bugs is all we need here. Please move specific discussions into the bugs themselves or start a new thread to talk about it... Replies on this thread should just be a collector for bug numbers. The simple answer is as always: fix all bugs I submitted ;) http://www.cmake.org/Bug/view.php?id=11333 FindThreads incorrectly adds -pthread to linker options http://www.cmake.org/Bug/view.php?id=7830 Likely a dupe of the above http://www.cmake.org/Bug/view.php?id=12054 FindJava.cmake too noisy on second run http://www.cmake.org/Bug/view.php?id=10740 This has been fixed in 2.8.4, but the doc update was not committed http://www.cmake.org/Bug/view.php?id=10476 No program output if CTest aborts test with timeout http://www.cmake.org/Bug/view.php?id=11792 Improve handling of CTEST_SITE http://www.cmake.org/Bug/view.php?id=11792 Code comments for many commands are wrong (copypaste) http://www.cmake.org/Bug/view.php?id=8466 Provide finer control than pass/fail for a test program Here are also some bugs that are resolved and can be closed as they are fixed in 2.8.4: http://www.cmake.org/Bug/view.php?id=11362 http://www.cmake.org/Bug/view.php?id=11329 http://www.cmake.org/Bug/view.php?id=11791 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Bug fix requests for the *next* release of CMake...
When using external_project, if GIT_TAG is modified the entire source tree is removed and re-cloned causing a full rebuild of said project. http://cmake.org/Bug/view.php?id=11403 On Tue, Mar 29, 2011 at 1:56 PM, David Cole david.c...@kitware.com wrote: Hi all, Now that we have released CMake 2.8.4, *now* would be a great time to prioritize bug fixes for the next release of CMake. Replies requested. Read on. *Just a short reply with bug numbers* or links to the bugs is all we need here. Please move specific discussions into the bugs themselves or start a new thread to talk about it... Replies on this thread should just be a collector for bug numbers. We are aiming for quarterly releases from now on, scheduling them every 3 or 4 months. That would make the next release of CMake version 2.8.5, scheduled to have an rc1 release candidate on Wed. April 27, 2011. If you have a particular issue that you think should be fixed for inclusion in 2.8.5, please bring it up by the end of this week. 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 an 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, basically any patch with testing is 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 as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed for 2.8.5 -- we will be looking at the mailing list and activity in the bug tracker to help prioritize the bug fixes that will occur over the next 4 weeks. Thanks, David Cole Kitware, Inc. P.S. - as a nice summary of what we accomplished in the CMake 2.8.4 release, see here: http://public.kitware.com/Bug/changelog_page.php -- it currently lists 127 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.3... Don't be shy!) ___ cmake-developers mailing list cmake-develop...@cmake.org 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Bug fix requests for the *next* release of CMake...
2011/3/29 David Cole david.c...@kitware.com: Please discuss issues here as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed for 2.8.5 -- we will be looking at the mailing list and activity in the bug tracker to help prioritize the bug fixes that will occur over the next 4 weeks. http://public.kitware.com/Bug/view.php?id=8438 http://public.kitware.com/Bug/view.php?id=10067 http://public.kitware.com/Bug/view.php?id=11656 http://public.kitware.com/Bug/view.php?id=11944 I'll try to work on the last 3 but any help for those will be appreciated. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ 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-developers] Bug fix requests for the *next* release of CMake...
Eric, those all look good, but I'd like to particularly +1 this one: http://public.kitware.com/Bug/view.php?id=8438 I've hacked around this deficiency in several places and I'm sure other users have as well. It would be nice to replace these hacks with a nice simple solution. Thanks, tyler On Tue, Mar 29, 2011 at 12:38 PM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/29 David Cole david.c...@kitware.com: Please discuss issues here as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed for 2.8.5 -- we will be looking at the mailing list and activity in the bug tracker to help prioritize the bug fixes that will occur over the next 4 weeks. http://public.kitware.com/Bug/view.php?id=8438 http://public.kitware.com/Bug/view.php?id=10067 http://public.kitware.com/Bug/view.php?id=11656 http://public.kitware.com/Bug/view.php?id=11944 I'll try to work on the last 3 but any help for those will be appreciated. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ 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] [cmake-developers] Bug fix requests for the *next* release of CMake...
I'll third that. I'd like to see 8438 addressed as well. -Mike On 03/29/2011 02:56 PM, Tyler wrote: Eric, those all look good, but I'd like to particularly +1 this one: http://public.kitware.com/Bug/view.php?id=8438 I've hacked around this deficiency in several places and I'm sure other users have as well. It would be nice to replace these hacks with a nice simple solution. Thanks, tyler On Tue, Mar 29, 2011 at 12:38 PM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/29 David Cole david.c...@kitware.com: Please discuss issues here as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed for 2.8.5 -- we will be looking at the mailing list and activity in the bug tracker to help prioritize the bug fixes that will occur over the next 4 weeks. http://public.kitware.com/Bug/view.php?id=8438 http://public.kitware.com/Bug/view.php?id=10067 http://public.kitware.com/Bug/view.php?id=11656 http://public.kitware.com/Bug/view.php?id=11944 I'll try to work on the last 3 but any help for those will be appreciated. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ 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 ___ 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-developers] Bug fix requests for the *next* release of CMake...
Hi David, I've got one more, one that I just entered in Mantis. #11410 - Result of IF(LIST) is inconsistent 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
Re: [CMake] [cmake-developers] Bug fix requests for the *next* release of CMake...
I am not sure if this is a reported bug (I can report it now if it isn't reported already). Using ExternalProject with a git repo and specifying a sha1 revision via GIT_TAG will blow away the entire source directory whenever the revision is changed. This leads to complete rebuilds of said project. On Thu, Nov 4, 2010 at 3:34 PM, David Cole david.c...@kitware.com wrote: Hi all, Now that we have released CMake 2.8.3, *now* would be a great time to prioritize bug fixes for the next release of CMake. Replies requested. Read on. *Just a short reply with bug numbers* or links to the bugs is all we need here. Please move specific discussions into the bugs themselves or start a new thread to talk about it... Replies on this thread should just be a collector for bug numbers. We are aiming for quarterly releases from now on, scheduling them every 3 or 4 months. That would make the next release of CMake version 2.8.4 and scheduled to have an rc1 release candidate in approximately mid-January, 2011, target date: Wed. 1/12/2011. If you have a particular issue that you think should be fixed for inclusion in 2.8.4, please bring it up now. 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 an 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, basically any patch with testing is 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 as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed for 2.8.4 -- we will be looking at the mailing list and activity in the bug tracker to help prioritize the bug fixes that will occur in the next several weeks. Thanks, David Cole Kitware, Inc. P.S. - as a nice summary of what we've accomplished in the CMake 2.8.3 release, see here: http://public.kitware.com/Bug/changelog_page.php -- it lists 89 issues that we resolved: nice job, everybody! (About 45 of those were specifically addressed because somebody brought it up in response to my similar email from just after 2.8.2... Don't be shy!) ___ cmake-developers mailing list cmake-develop...@cmake.org 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Bug fix requests for the *next* release of CMake...
VS 2010 CMake plugin is broken http://www.vtk.org/Bug/view.php?id=11258 This is a problem for projects such as mine where I have dozens of projects in my solution and they can change rather frequently, especially with my FindCUDA.cmake script that computes dependencies and then changes the VS projects. Thanks, James ___ 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-developers] Bug fix requests for the *next* release of CMake...
I'll vote for that bug. I _was_ going to load VS2010 but maybe I'll hold off. ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio On Nov 4, 2010, at 4:28 PM, James Bigler wrote: VS 2010 CMake plugin is broken http://www.vtk.org/Bug/view.php?id=11258 This is a problem for projects such as mine where I have dozens of projects in my solution and they can change rather frequently, especially with my FindCUDA.cmake script that computes dependencies and then changes the VS projects. Thanks, James ___ 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] [cmake-developers] Bug fix requests for the *next* release of CMake...
2010/11/4 David Cole david.c...@kitware.com: Hi all, Now that we have released CMake 2.8.3, *now* would be a great time to prioritize bug fixes for the next release of CMake. Replies requested. Read on. Just a short reply with bug numbers or links to the bugs is all we need here. Please move specific discussions into the bugs themselves or start a new thread to talk about it... Replies on this thread should just be a collector for bug numbers. http://cmake.org/Bug/view.php?id=11404 http://cmake.org/Bug/view.php?id=7645 + same idea for Debian Package see ML http://www.cmake.org/pipermail/cmake/2010-October/040321.html and http://purplekarrot.net/blog/dputCMake.html + Add More CTest test for CPack generators inside the CMake tree. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ 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-developers] Bug fix requests for the *next* release of CMake...
Great idea! There is now a roadmap page in Mantis for the CMake project. http://public.kitware.com/Bug/roadmap_page.php It has 33 issues listed as targeted for 2.8.3. 17 of these (51%) are resolved: fixed in 'next' already, or won't fix... ever. The remaining 16 shall be fixed (or marked as postponed to the next release) over the next couple of weeks, and then we'll be ready for the first RC of CMake 2.8.3. Thanks to all of you who participated in this thread. It helped us organize around what people think is most important. Cheers, David Cole Kitware, Inc. P.S. -- there were 40-something issues mentioned specifically in this thread. The 33 listed on the roadmap plus the following 13, which we decided should be looked at for a future release, if ever, but certainly not in the time remaining before 2.8.3 http://public.kitware.com/Bug/view.php?id=5796 http://public.kitware.com/Bug/view.php?id=7867 http://public.kitware.com/Bug/view.php?id=7919 http://public.kitware.com/Bug/view.php?id=8466 http://public.kitware.com/Bug/view.php?id=8486 http://public.kitware.com/Bug/view.php?id=10199 http://public.kitware.com/Bug/view.php?id=10200 http://public.kitware.com/Bug/view.php?id=10335 http://public.kitware.com/Bug/view.php?id=10389 http://public.kitware.com/Bug/view.php?id=10476 http://public.kitware.com/Bug/view.php?id=10752 http://public.kitware.com/Bug/view.php?id=10895 http://public.kitware.com/Bug/view.php?id=10939 There should be a note attached to each of these that says something like not working on this for 2.8.3... Thanks, D. On Fri, Jul 30, 2010 at 4:18 PM, Brian Davis bitmi...@gmail.com wrote: Can a roadmap be posted for CMake? Such as is for other projects at: http://www.cmake.org/Bug/roadmap_page.php ___ 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-developers] Bug fix requests for the *next* release of CMake...
David, Thanks for enabling this. If anyone is wondering where to find the Target Release and Fixed In Version fields, they are under the Advanced Details link for each bug. When you mark a bug as fixed, it prompts you for Fixed In Version but the only way to set Target Release I can see is under Advanced (just an FYI for people). On Tue, Aug 31, 2010 at 6:35 PM, David Cole david.c...@kitware.com wrote: Great idea! There is now a roadmap page in Mantis for the CMake project. http://public.kitware.com/Bug/roadmap_page.php It has 33 issues listed as targeted for 2.8.3. 17 of these (51%) are resolved: fixed in 'next' already, or won't fix... ever. The remaining 16 shall be fixed (or marked as postponed to the next release) over the next couple of weeks, and then we'll be ready for the first RC of CMake 2.8.3. Thanks to all of you who participated in this thread. It helped us organize around what people think is most important. Cheers, David Cole Kitware, Inc. P.S. -- there were 40-something issues mentioned specifically in this thread. The 33 listed on the roadmap plus the following 13, which we decided should be looked at for a future release, if ever, but certainly not in the time remaining before 2.8.3 http://public.kitware.com/Bug/view.php?id=5796 http://public.kitware.com/Bug/view.php?id=7867 http://public.kitware.com/Bug/view.php?id=7919 http://public.kitware.com/Bug/view.php?id=8466 http://public.kitware.com/Bug/view.php?id=8486 http://public.kitware.com/Bug/view.php?id=10199 http://public.kitware.com/Bug/view.php?id=10200 http://public.kitware.com/Bug/view.php?id=10335 http://public.kitware.com/Bug/view.php?id=10389 http://public.kitware.com/Bug/view.php?id=10476 http://public.kitware.com/Bug/view.php?id=10752 http://public.kitware.com/Bug/view.php?id=10895 http://public.kitware.com/Bug/view.php?id=10939 There should be a note attached to each of these that says something like not working on this for 2.8.3... Thanks, D. On Fri, Jul 30, 2010 at 4:18 PM, Brian Davis bitmi...@gmail.com wrote: Can a roadmap be posted for CMake? Such as is for other projects at: http://www.cmake.org/Bug/roadmap_page.php ___ cmake-developers mailing list cmake-develop...@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Philip Lowman ___ 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-developers] Bug fix requests for the *next* release of CMake...
Can a roadmap be posted for CMake? Such as is for other projects at: http://www.cmake.org/Bug/roadmap_page.php ___ 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-developers] Bug fix requests for the *next* release of CMake...
2010/7/5 David Cole david.c...@kitware.com: Hi all, Now that we have released CMake 2.8.2 last Monday, and we have switched to this new workflow using branches in the git repository, *now* would be a great time to prioritize bug fixes for the next release of CMake. We are leaning towards quarterly releases from now on, scheduling them every 3 months. That would make the next release of CMake version 2.8.3 and scheduled to have an rc1 release candidate in approximately mid-September, 2010. If you have a particular issue that you think should be fixed for inclusion in 2.8.3, please bring it up now. 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 an 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, basically any patch with testing is 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 as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed for 2.8.3 -- we will be looking at the mailing list and activity in the bug tracker to help prioritize the bug fixes that will occur in the next several weeks. Thanks, David Cole Kitware, Inc. So here goes my own list. I'd like to fix 2 annoying relatively long-standing bugs: 1) Make CPack generic generator delegate the name of the file to specific generator http://public.kitware.com/Bug/view.php?id=9900 (may be fixed together with http://public.kitware.com/Bug/view.php?id=10736) 2) CPack RPM generator should always CPACK_SET_DESTDIR http://public.kitware.com/Bug/view.php?id=7000 1) Should come first because it will help fix others depending bugs related to this one and makes it possible to use standard package name for at least RPM and DEB. May be it can be fixed together with http://public.kitware.com/Bug/view.php?id=10736. The idea would be for the CPack generic generator to offer a new compresFiles API in which the name of the package is both an input AND an output. Moreover the output should be a vector of filenames and not a single filename. 2) In the same way this one is blocking some pending features for CPackRPM (or CPackDEB) and the issue is raising from time to time on the list. May be interested people could add themselves to the monitor list of those bugs. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ 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-developers] Bug fix requests for the *next* release of CMake...
On Thu, Jul 29, 2010 at 6:33 PM, Eric Noulard eric.noul...@gmail.com wrote: 2010/7/5 David Cole david.c...@kitware.com: Now that we have released CMake 2.8.2 last Monday, and we have switched to this new workflow using branches in the git repository, *now* would be a great time to prioritize bug fixes for the next release of CMake. I'd like to see those fixed: http://public.kitware.com/Bug/view.php?id=11030 http://public.kitware.com/Bug/view.php?id=11031 It'd make building libs on Windows way easier. Last week I had to build bzip2, ogg, vorbis, zlib, jpeg and png. Some ship (old) VS project files, but none suit my needs by default. Being able to use CMake to build the necessary configs, ensuring they have proper names and ideally copying them all to a single dir would be awesome. Olaf ___ 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-developers] Bug fix requests for the *next* release of CMake...
I'd like to see those fixed: http://public.kitware.com/Bug/view.php?id=11030 That one is closed. ___ 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-developers] Bug fix requests for the *next* release of CMake...
http://public.kitware.com/Bug/view.php?id=10388 Patch was already included I would also vote for project_group to get applied. I'd also like to see support for additional compile flags based on target http://public.kitware.com/Bug/view.php?id=10389 On Mon, Jul 5, 2010 at 11:31 AM, David Cole david.c...@kitware.com wrote: Hi all, Now that we have released CMake 2.8.2 last Monday, and we have switched to this new workflow using branches in the git repository, *now* would be a great time to prioritize bug fixes for the next release of CMake. We are leaning towards quarterly releases from now on, scheduling them every 3 months. That would make the next release of CMake version 2.8.3 and scheduled to have an rc1 release candidate in approximately mid-September, 2010. If you have a particular issue that you think should be fixed for inclusion in 2.8.3, please bring it up now. 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 an 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, basically any patch with testing is 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 as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed for 2.8.3 -- we will be looking at the mailing list and activity in the bug tracker to help prioritize the bug fixes that will occur in the next several weeks. Thanks, David Cole Kitware, Inc. ___ cmake-developers mailing list cmake-develop...@cmake.org 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Bug fix requests for the *next* release of CMake...
On Thu, Jul 29, 2010 at 6:59 PM, Verweij, Arjen verwe...@tass-safe.com wrote: I'd like to see those fixed: http://public.kitware.com/Bug/view.php?id=11030 That one is closed. Yes, unfortunately. I don't agree with that decision. Olaf ___ 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-developers] Bug fix requests for the *next* release of CMake...
On 29. Jul, 2010, at 19:26 , Olaf van der Spek wrote: On Thu, Jul 29, 2010 at 6:59 PM, Verweij, Arjen verwe...@tass-safe.com wrote: I'd like to see those fixed: http://public.kitware.com/Bug/view.php?id=11030 That one is closed. Yes, unfortunately. I don't agree with that decision. Olaf The problem is that there IS NO CONVENTION on name decoration. And yes, especially as a library developer you have to be aware of things. The application programmer doesn't want/have to care about them ;-) Michael ___ 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-developers] Bug fix requests for the *next* release of CMake...
On Thu, Jul 29, 2010 at 11:13 PM, Michael Wild them...@gmail.com wrote: The problem is that there IS NO CONVENTION on name decoration. Why is that a problem? And yes, especially as a library developer you have to be aware of things. Why? Olaf ___ 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-developers] Bug fix requests for the *next* release of CMake...
On Thu, Jul 29, 2010 at 2:22 PM, Olaf van der Spek olafvds...@gmail.com wrote: On Thu, Jul 29, 2010 at 11:13 PM, Michael Wild them...@gmail.com wrote: The problem is that there IS NO CONVENTION on name decoration. Why is that a problem? well that any convention that YOU want, since there is no standard outside of what YOU desire, means you need to apply naming conventions to meat YOUR criteria. And yes, especially as a library developer you have to be aware of things. Why? Becuase it's something YOU desire, that the rest of the world rarely uses. I've seen less than half a dozen projects that attempt to do that, and then have to fight with converting their projects to use just standard names of libraries I already have (strip off _debug and d's appended to library names for no good reason). The product of a single build type is put in a single place all together, so why would there ever be a mixture. How many libraries under linux actually install realease and debug together? and under windows there is no particular standard for where to install things, so it's entirely open for you to manipulate how you want. Olaf ___ 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] [cmake-developers] Bug fix requests for the *next* release of CMake...
On 29. Jul, 2010, at 23:22 , Olaf van der Spek wrote: On Thu, Jul 29, 2010 at 11:13 PM, Michael Wild them...@gmail.com wrote: The problem is that there IS NO CONVENTION on name decoration. Why is that a problem? If CMake made the choice, somebody (i.e. exactly ONE person) would be a happy camper, all the others would have froth in front of their mouths... It is trivial to add the decoration yourself, if you must wrap add_executable and add_library in a custom function which sets the properties appropriately. And yes, especially as a library developer you have to be aware of things. Why? A library developer has to think of everything. Otherwise the library is useless. Good libraries are carefully crafted pieces of art, where the developer tried to mold the interface and the functionality in a way that allows for greatest flexibility, trying very hard not to do it the easy way and just hack it together so it works for just this single application. He is an enabler, the creator of all the infrastructure, the very heart of a software project. He has to know every detail and all the implications of the actions he takes. So, as a library developer you pretty damn well care about everything, even naming of the libraries, because you don't just provide an application, you create a whole development kit which you intend to be used by others in ways you couldn't imagine. On the other hand, the application programmer just assembles the pieces in new, often ingenious ways ;-) Michael ___ 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-developers] Bug fix requests for the *next* release of CMake...
On Thu, Jul 29, 2010 at 11:45 PM, J Decker d3c...@gmail.com wrote: On Thu, Jul 29, 2010 at 2:22 PM, Olaf van der Spek olafvds...@gmail.com wrote: On Thu, Jul 29, 2010 at 11:13 PM, Michael Wild them...@gmail.com wrote: The problem is that there IS NO CONVENTION on name decoration. Why is that a problem? well that any convention that YOU want, since there is no standard outside of what YOU desire, means you need to apply naming conventions to meat YOUR criteria. I'm still not sure what the problem is. And yes, especially as a library developer you have to be aware of things. Why? Becuase it's something YOU desire, that the rest of the world rarely uses. I've seen less than half a dozen projects that attempt to do that, and then have to fight with converting their projects to use just standard names of libraries I already have (strip off _debug and d's appended to library names for no good reason). The product of a Why is the -d suffix a problem for you? single build type is put in a single place all together, so why would there ever be a mixture. How many libraries under linux actually install realease and debug together? I'm not talking about Linux. and under windows there is no particular standard for where to install things, so it's entirely open for you to manipulate how you want. Putting libs in the lib dir so the linker can find them sounds like a good idea to me. It seems you're saying that since there's no standard yet, we shouldn't bother to improve the situation at all. Olaf ___ 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-developers] Bug fix requests for the *next* release of CMake...
On Thu, Jul 29, 2010 at 11:54 PM, Michael Wild them...@gmail.com wrote: If CMake made the choice, somebody (i.e. exactly ONE person) would be a happy camper, all the others would have froth in front of their mouths... Why? It is trivial to add the decoration yourself, if you must wrap add_executable and add_library in a custom function which sets the properties appropriately. Sounds like tons of code duplication, which might be trivial but is not a good thing. And yes, especially as a library developer you have to be aware of things. Why? A library developer has to think of everything. Otherwise the library is useless. Everything is a big word. Of course I disagree with you. Ever heard of abstractions? They're there so one doesn't have to bother with all the details. With CMake, I don't have to think about how to build stuff on tons of different platforms, CMake abstracts that for me. I don't see why it can't do the same for naming. Olaf ___ 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-developers] Bug fix requests for the *next* release of CMake...
On Jul 29, 2010, at 6:01 PM, Olaf van der Spek wrote: Everything is a big word. Of course I disagree with you. Ever heard of abstractions? They're there so one doesn't have to bother with all the details. With CMake, I don't have to think about how to build stuff on tons of different platforms, CMake abstracts that for me. I don't see why it can't do the same for naming. Olaf Because as a library developer YOU are responsible for making sure your library integrates well with the operating system you intend to deploy on it. Each Operating System has rules according to Person1, Person2, Person3 PersonN. It is up to YOU as the DEVELOPER of the library to pick something that makes sense for your project. And just because it makes sense for YOU does not mean it makes sense for MY project. ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio ___ 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-developers] Bug fix requests for the *next* release of CMake...
On Fri, Jul 30, 2010 at 12:04 AM, Michael Jackson mike.jack...@bluequartz.net wrote: Because as a library developer YOU are responsible for making sure your library integrates well with the operating system you intend to deploy on it. Each Operating System has rules according to Person1, Person2, Person3 PersonN. It is up to YOU as the DEVELOPER of the library to pick something that makes sense for your project. And just because it makes sense for YOU does not mean it makes sense for MY project. To be honest I've no idea what you're trying to say here. If you don't want name decoration then you don't enable it, it's so simple... Olaf ___ 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-developers] Bug fix requests for the *next* release of CMake...
I am saying that in the past 10 years of programming I found that there is NO standard, even within an Operating System itself. Some projects like a combined build of debug and release libraries with a d suffix on ALL platforms (Qt) even though OS X would have then put _debug. Another library, ITK, _really_ wants you to have distinct Debug and Release installation locations. They don't use ANY decorations. Boost, well, they went slap happy with their decorations and don't follow ANY standard (either perceived or real). The point is that if you want to integrate into any of those environments you better understand _their_ naming conventions, whether those conventions integrate with your chosen build environment and whether you are going to perpetuate someone else's standard or not. I'll leave the philosophical debate for somewhere else. After considering ALL of those factors (plus any thing else you deem important) then you make your decision about whether or not to decorate your libraries. Having the choice to do so is what CMake offers. To YOU, the default (no decorations) is WRONG. To the rest of us, the default is RIGHT. Your solution is valid. I will give you that. But the Default you propose is still wrong to the rest of us. If your solution was implemented but had a default of NO decoration you would still complain. As it is now CMake offers the functionality you want. ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio On Jul 29, 2010, at 6:07 PM, Olaf van der Spek wrote: On Fri, Jul 30, 2010 at 12:04 AM, Michael Jackson mike.jack...@bluequartz.net wrote: Because as a library developer YOU are responsible for making sure your library integrates well with the operating system you intend to deploy on it. Each Operating System has rules according to Person1, Person2, Person3 PersonN. It is up to YOU as the DEVELOPER of the library to pick something that makes sense for your project. And just because it makes sense for YOU does not mean it makes sense for MY project. To be honest I've no idea what you're trying to say here. If you don't want name decoration then you don't enable it, it's so simple... Olaf ___ 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-developers] Bug fix requests for the *next* release of CMake...
On 30.07.2010, at 00:07, Olaf van der Spek olafvds...@gmail.com wrote: On Fri, Jul 30, 2010 at 12:04 AM, Michael Jackson mike.jack...@bluequartz.net wrote: Because as a library developer YOU are responsible for making sure your library integrates well with the operating system you intend to deploy on it. Each Operating System has rules according to Person1, Person2, Person3 PersonN. It is up to YOU as the DEVELOPER of the library to pick something that makes sense for your project. And just because it makes sense for YOU does not mean it makes sense for MY project. To be honest I've no idea what you're trying to say here. If you don't want name decoration then you don't enable it, it's so simple... Olaf Just enable it, it' so simple. ___ 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-developers] Bug fix requests for the *next* release of CMake...
On Fri, Jul 30, 2010 at 12:18 AM, Michael Wild them...@gmail.com wrote: Just enable it, it' so simple. What's the name of the switch I have to enable? Olaf ___ 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-developers] Bug fix requests for the *next* release of CMake...
On Fri, Jul 30, 2010 at 12:16 AM, Michael Jackson mike.jack...@bluequartz.net wrote: I am saying that in the past 10 years of programming I found that there is NO standard, even within an Operating System itself. Some projects like a combined build of debug and release libraries with a d suffix on ALL platforms (Qt) even though OS X would have then put _debug. Another library, ITK, _really_ wants you to have distinct Debug and Release installation locations. They don't use ANY decorations. Boost, well, they went slap happy with their decorations and don't follow ANY standard (either perceived or real). The point is that if you want to integrate into any of those environments you better understand _their_ naming conventions, whether those conventions Why would the naming convention have to match? integrate with your chosen build environment and whether you are going to perpetuate someone else's standard or not. I'll leave the philosophical debate for somewhere else. After considering ALL of those factors (plus any thing else you deem important) then you make your decision about whether or not to decorate your libraries. Having the choice to do so is what CMake offers. To YOU, the default (no decorations) is WRONG. To the rest of us, the default is RIGHT. Why? I'm still waiting for someone to post a reason of why a decorated name is a problem for them. Also waiting on an answer to the code duplication issue. Your solution is valid. I will give you that. But the Default you propose is still wrong to the rest of us. If your solution was implemented but had a default of NO decoration you would still complain. I might complain, but that situation would be better than the current situation. As it is now CMake offers the functionality you want. It doesn't. I'd like CMake to generate libs with unique names and it doesn't... Olaf ___ 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-developers] Bug fix requests for the *next* release of CMake...
On Fri, Jul 30, 2010 at 12:28 AM, Michael Jackson mike.jack...@bluequartz.net wrote: On Jul 29, 2010, at 6:24 PM, Olaf van der Spek wrote: As it is now CMake offers the functionality you want. It doesn't. I'd like CMake to generate libs with unique names and it doesn't... It DOES. The cmake code has been posted on how to do it. Done. Why are you not addressing over half of my questions? Olaf ___ 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-developers] Bug fix requests for the *next* release of CMake...
Why? I'm still waiting for someone to post a reason of why a decorated name is a problem for them. Also waiting on an answer to the code duplication issue. An automatic naming scheme could break existing applications that search for plugins based on their names. Some of those developers may already be controlling their names explicitly, but some may not. Clint ___ 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-developers] Bug fix requests for the *next* release of CMake...
On Fri, Jul 30, 2010 at 1:00 AM, Clinton Stimpson clin...@elemtech.com wrote: Why? I'm still waiting for someone to post a reason of why a decorated name is a problem for them. Also waiting on an answer to the code duplication issue. An automatic naming scheme could break existing applications that search for plugins based on their names. Some of those developers may already be controlling their names explicitly, but some may not. Good point, so let's make it opt-in. Olaf ___ 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-developers] Bug fix requests for the *next* release of CMake...
I really wish you guys would have had this conversation on a separate thread dedicated to the topic. (Oh wait, there already was one...) Please take it to another thread, and leave this one as Bug fix requests for the *next* release of CMake... Thanks, David On Thu, Jul 29, 2010 at 7:01 PM, Olaf van der Spek olafvds...@gmail.comwrote: On Fri, Jul 30, 2010 at 1:00 AM, Clinton Stimpson clin...@elemtech.com wrote: Why? I'm still waiting for someone to post a reason of why a decorated name is a problem for them. Also waiting on an answer to the code duplication issue. An automatic naming scheme could break existing applications that search for plugins based on their names. Some of those developers may already be controlling their names explicitly, but some may not. Good point, so let's make it opt-in. Olaf ___ 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
