Re: [cmake-developers] Preparing for 2.8.11-rc1
On Monday 04 March 2013, Stephen Kelly wrote: > On 03/04/2013 02:58 PM, Brad King wrote: > > Stephen, > > > > We originally wanted to start the 2.8.11 release candidate series at > > the end of January. We've delayed it while your usage requirements > > feature has cooked. Even last week you were polishing up a few subtle > > corrections, so it was worth the wait. > > > > Normally we try to avoid delaying a new release for a feature still > > under development but this one required such pervasive changes that > > it would have been impractical to develop it on a separate branch. > > Since it is in master we have to wait until it is ready before we > > can release again. However, there are many other features and bug > > fixes since 2.8.10 for which people are awaiting 2.8.11. > > > > Do you feel the feature has become mature enough for release? Are > > there any other tests or use cases under development elsewhere on > > which we should wait? > > Hi, > > I have not tried again to implement a proof of concept of the list > handling after the discussion about it last week. This week I don't > think I can commit to it either, but I'm not overly concerned about it > after the discussion we had. It might make sense to put the unit test > change from > > > https://gitorious.org/~steveire/cmake/steveires-cmake/commit/96ec58003de58 > 3794fb7440fc4b3521f272a26d6 > > in, but then again, the behavior of code like that won't change until > the next release, and a policy will probably be needed anyway. > > I don't have other new tests or features aimed for 2.8.11. It would be > nice to 'fix' cmGeneratorExpression::Split handling of escaped > semicolons and square brackets, but I don't think I'll have time to do > that, and I think it can wait until the following release anyway. > > So, I think it's mature enough for release now, yes. did you get around to add handling for usr-move to the relative directory references for exports-files ? Otherwise I'll see whether I find time this week. 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] Preparing for 2.8.11-rc1
On 03/04/2013 11:15 AM, Stephen Kelly wrote: > I have not tried again to implement a proof of concept of the list > handling after the discussion about it last week. This week I don't > think I can commit to it either, but I'm not overly concerned about it > after the discussion we had. That discussion concluded by deciding to wait until after 2.8.11. > It might make sense to put the unit test change from > > > https://gitorious.org/~steveire/cmake/steveires-cmake/commit/96ec58003de583794fb7440fc4b3521f272a26d6 > > in, but then again, the behavior of code like that won't change until > the next release, and a policy will probably be needed anyway. I think it will be better to leave it because then the test will expose the change in behavior and can be used to cover the policy. > I don't have other new tests or features aimed for 2.8.11. It would be > nice to 'fix' cmGeneratorExpression::Split handling of escaped > semicolons and square brackets, but I don't think I'll have time to do > that, and I think it can wait until the following release anyway. Agreed. > So, I think it's mature enough for release now, yes. Great, 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] Preparing for 2.8.11-rc1
On 03/04/2013 02:58 PM, Brad King wrote: Stephen, We originally wanted to start the 2.8.11 release candidate series at the end of January. We've delayed it while your usage requirements feature has cooked. Even last week you were polishing up a few subtle corrections, so it was worth the wait. Normally we try to avoid delaying a new release for a feature still under development but this one required such pervasive changes that it would have been impractical to develop it on a separate branch. Since it is in master we have to wait until it is ready before we can release again. However, there are many other features and bug fixes since 2.8.10 for which people are awaiting 2.8.11. Do you feel the feature has become mature enough for release? Are there any other tests or use cases under development elsewhere on which we should wait? Hi, I have not tried again to implement a proof of concept of the list handling after the discussion about it last week. This week I don't think I can commit to it either, but I'm not overly concerned about it after the discussion we had. It might make sense to put the unit test change from https://gitorious.org/~steveire/cmake/steveires-cmake/commit/96ec58003de583794fb7440fc4b3521f272a26d6 in, but then again, the behavior of code like that won't change until the next release, and a policy will probably be needed anyway. I don't have other new tests or features aimed for 2.8.11. It would be nice to 'fix' cmGeneratorExpression::Split handling of escaped semicolons and square brackets, but I don't think I'll have time to do that, and I think it can wait until the following release anyway. So, I think it's mature enough for release now, yes. All the best, 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] Preparing for 2.8.11-rc1
Stephen, We originally wanted to start the 2.8.11 release candidate series at the end of January. We've delayed it while your usage requirements feature has cooked. Even last week you were polishing up a few subtle corrections, so it was worth the wait. Normally we try to avoid delaying a new release for a feature still under development but this one required such pervasive changes that it would have been impractical to develop it on a separate branch. Since it is in master we have to wait until it is ready before we can release again. However, there are many other features and bug fixes since 2.8.10 for which people are awaiting 2.8.11. Do you feel the feature has become mature enough for release? Are there any other tests or use cases under development elsewhere on which we should wait? 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
[cmake-developers] [CMake 0013973]: patch for fix FindThreads on haiku
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13973 == Reported By:diger Assigned To: == Project:CMake Issue ID: 13973 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2013-03-04 04:34 EST Last Modified: 2013-03-04 04:34 EST == Summary:patch for fix FindThreads on haiku Description: This patch workarounds issue with pthreads on Haiku platform. The source of problem was that pthreads support is implemented in libroot. == Issue History Date ModifiedUsername FieldChange == 2013-03-04 04:34 diger New Issue 2013-03-04 04:34 diger File Added: patch-Modules_FindThreads.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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
