Re: [cmake-developers] Preparing for 2.8.11-rc1
On 3/7/2013 5:13 PM, Brad King wrote: On 03/07/2013 04:09 PM, Alexander Neundorf wrote: IOW: without this fix cmake's exported target files are non-working on usr- move systems if installed into one of the affected directories. That's IMO a blocker. It's no worse than 2.8.10. Whatever fix you produce can be backported into whatever version those distros have. I apologize for the tone in my last couple responses to you in this thread. This is Much Ado About Nothing as the change isn't hard: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0c727b90 For completeness I responded in the original thread so please follow up there if you have any feedback. -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/07/2013 02:22 AM, Stephen Kelly wrote: Oh, ok, here I assumed you would have finished it in the meantime. Can you try to get this in shape for 2.8.11 ? No, I'm afraid not. We're not going to delay 2.8.11 further for a not-yet-developed feature anyway. -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 Thursday 07 March 2013, Brad King wrote: On 03/07/2013 02:22 AM, Stephen Kelly wrote: Oh, ok, here I assumed you would have finished it in the meantime. Can you try to get this in shape for 2.8.11 ? No, I'm afraid not. We're not going to delay 2.8.11 further for a not-yet-developed feature anyway. Well, the usr-move fix must go in. Otherwise all installed Config-files on usr-move distros which have references outside lib/ (e.g. into bin/ or include/) are broken. I think I won't manage to get that working tomorrow, but next week then. 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/07/2013 03:47 PM, Alexander Neundorf wrote: On Thursday 07 March 2013, Brad King wrote: We're not going to delay 2.8.11 further for a not-yet-developed feature anyway. Well, the usr-move fix must go in. Otherwise all installed Config-files on usr-move distros which have references outside lib/ (e.g. into bin/ or include/) are broken. I think I won't manage to get that working tomorrow, but next week then. ...or those distros can add the patch to their 2.8.11. We originally wanted to do 2.8.11-rc1 on Feb 1 but delayed to wait for Stephen's changes to mature. You've had weeks to get this change done. -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 Thursday 07 March 2013, Brad King wrote: On 03/07/2013 03:47 PM, Alexander Neundorf wrote: On Thursday 07 March 2013, Brad King wrote: We're not going to delay 2.8.11 further for a not-yet-developed feature anyway. Well, the usr-move fix must go in. Otherwise all installed Config-files on usr-move distros which have references outside lib/ (e.g. into bin/ or include/) are broken. I think I won't manage to get that working tomorrow, but next week then. ...or those distros can add the patch to their 2.8.11. We originally wanted to do 2.8.11-rc1 on Feb 1 but delayed to wait for Stephen's changes to mature. You've had weeks to get this change done. Yes, I know. I assumed Stephen would do that since he put all the work with the include- dirs etc. in. IOW: without this fix cmake's exported target files are non-working on usr- move systems if installed into one of the affected directories. That's IMO a blocker. 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 Tuesday 05 March 2013, Stephen Kelly wrote: Alexander Neundorf wrote: 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. I didn't work more on that, no, as I wrote here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5868/focu s=5985 Ok, I wasn't sure about this. I'll have a look at it in the next days. You may have already realised that, for the same reason, I didn't work more on this stuff either: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6106/focu s=6161 That branch was just a proof of concept. Oh, ok, here I assumed you would have finished it in the meantime. Can you try to get this in shape for 2.8.11 ? 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 Wednesday 06 March 2013, Brad King wrote: On 3/5/2013 5:05 PM, Stephen Kelly wrote: Stephen Kelly wrote: So, I think it's mature enough for release now, yes. It might be worth documenting it a bit more prominently though... Any opinion on this? I think the patch can be simpler: -through variables documented by the package itself. +through variables and imported targets documented by the package itself. IMO it is up to the package to advertise imported targets in its documentation. I think it's cool and a really good thing that imported targets can do more stuff now. It should also be documented well so that people are aware that the results if find_package(SomePackage) or no longer necessarily only file paths and directories, but also imported targets. But I think it's a step backward to use imported target names directly. One thing cmake users do complain about regularly is that they can't rely on what the names of the variables defined after find_package(SomePackage) are, even though there are guidelines for the naming in readme.txt. The results may be SOMEPACKAGE_LIBS, SOMEPACKAGE_LIBRARY, SOMEPACKAGE_LIBRARIES, SomePackage_LIBS, SomePackage_LIBRARY, SomePackage_LIBRARIES This is the one single strongest complaint I hear about using find_package(). We should try to fix this complaint by making the Find-modules/Config-files comply as good as possible to readme.txt, which we agreed upon that the correct name would be SomePackage_LIBRARIES. If we concentrate on that, using find_package() will become easier, since the variables will follow the standard naming. If we reach this, we'll have real progress, and we'll have made cmake really easier to use. If we now instead of following that strategy, start to recommend that packages may also document their exported/imported targets, we go in the opposite direction. When doing find_package(SomePackage) the user now again will have to read the documentation, just to find out whether he should use SomePackage_LIBRARIES or the imported target somepackagelib directly. So there would be two competing standards then ;-) Additionally, currently there are no guidelines for how exported/imported targets should be named, so besides having to find out whether targets should be used directly, they would have to read the documentation to find out how those targets are named. If we recommend using imported target names directory, readme.txt should contain guidelines for how to name the targets and namespaces. Also, using imported target names directly removes the isolation layer between in-project developers and how they name their targets, and users of their projects, which is by now provided by the variables set in Find- modules/Config-files. Another idea would by to have a new, additional standard variable SomePackage_TARGET or something like this. This would keep the advantage of the isolation layer, and the advantage of the standard naming, it would also make it visible that the thing is a target and may have include dirs attached, the downside would still be that the user has to find out whether he is supposed to use SomePackage_TARGET or SomePackage_LIBRARIES. 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
Stephen Kelly wrote: https://gitorious.org/~steveire/cmake/steveires-cmake/commit/96ec58003de583 794fb7440fc4b3521f272a26d6 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. So you introduce new stuff now and intend to change the way it works in the next release? Or you intend to change the way old stuff works in next release? 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] Preparing for 2.8.11-rc1
Alexander Neundorf wrote: You may have already realised that, for the same reason, I didn't work more on this stuff either: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6106/focu s=6161 That branch was just a proof of concept. Oh, ok, here I assumed you would have finished it in the meantime. Can you try to get this in shape for 2.8.11 ? No, I'm afraid not. I'm not certain the approach I took was the correct one, and I'm not taking over responsibility for the feature completely in general. My patch would cause a fatal_error if an imported target (either generated or hand-written) has a target in its link interface which does not exist (even if it is not used). From my reading of what Brad wrote, that's plausible: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6106/focus=6138 also, as the ImportInfo is retrieved when exporting targets, you may need to consider whether that can/should raise a fatal_error too. So, I think there's more work to do on that feature on several levels, and in the interest of being clear :), I'm not taking over responsibility for that work, though I'll help with code snippets as I did before. 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
Re: [cmake-developers] Preparing for 2.8.11-rc1
Alexander Neundorf wrote: 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. I didn't work more on that, no, as I wrote here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5868/focus=5985 You may have already realised that, for the same reason, I didn't work more on this stuff either: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6106/focus=6161 That branch was just a proof of concept. 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
Re: [cmake-developers] Preparing for 2.8.11-rc1
Stephen Kelly wrote: So, I think it's mature enough for release now, yes. It might be worth documenting it a bit more prominently though... Any opinion on this? Thanks, Author: Stephen Kelly steve...@gmail.com Date: Tue Mar 5 23:01:22 2013 +0100 Mention that IMPORTED targets may be created by a find_package call. diff --git a/Source/cmFindPackageCommand.cxx b/Source/cmFindPackageCommand.cxx index 470ceca..cf60351 100644 --- a/Source/cmFindPackageCommand.cxx +++ b/Source/cmFindPackageCommand.cxx @@ -95,7 +95,8 @@ void cmFindPackageCommand::GenerateDocumentation() Finds and loads settings from an external project. package_FOUND will be set to indicate whether the package was found. When the package is found package-specific information is provided -through variables documented by the package itself. +through variables documented by the package itself. Packages may also +define imported targets for use with target_link_libraries. The QUIET option disables messages if the package cannot be found. The MODULE option disables the second signature documented below. The REQUIRED option stops processing with an error message if the -- 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 3/5/2013 5:05 PM, Stephen Kelly wrote: Stephen Kelly wrote: So, I think it's mature enough for release now, yes. It might be worth documenting it a bit more prominently though... Any opinion on this? I think the patch can be simpler: -through variables documented by the package itself. +through variables and imported targets documented by the package itself. IMO it is up to the package to advertise imported targets in its documentation. -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
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 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
