Re: [cmake-developers] Windows symbolic links handling
On 08/24/2017 03:19 AM, Manu wrote: > I have fixed it but I am struggling with the new policy. The > behaviour change goes into cmSystemTools::GetRealPath implementation > and SystemTools has no context, so I am not sure how to check the policy. The policy would have to be checked higher in the stack and used to choose alternative implementations. > Mimicking policy CMP0067 usage, I could create an old and a new version > of GetRealPath and check for the policy prior calling it all along the code. > On the other hand, I could pass the policy status as a parameter to every > GetRealPath call. Which is the proper way? Likely a second API would be needed. The KWSys GetRealPath could be taught to handle symlinks on Windows. If it turns out a policy is needed then a cmSystemTools:: alternative in CMake only could be added. > To perform a pull request, should I previously open an issue about > this or it is enough with the discusion here in the mailing list. For reference, this issue has been opened: https://gitlab.kitware.com/cmake/cmake/issues/17206 I think we can try this without a policy first. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Windows symbolic links handling
Hello, I have fixed it but I am struggling with the new policy. The behaviour change goes into cmSystemTools::GetRealPath implementation and SystemTools has no context, so I am not sure how to check the policy. Mimicking policy CMP0067 usage, I could create an old and a new version of GetRealPath and check for the policy prior calling it all along the code. On the other hand, I could pass the policy status as a parameter to every GetRealPath call. Which is the proper way? To perform a pull request, should I previously open an issue about this or it is enough with the discusion here in the mailing list. Regards. 2017-08-16 11:35 GMT+02:00 Manu : > > > 2017-08-15 16:43 GMT+02:00 Brad King : > >> On 08/14/2017 06:35 AM, Manu wrote: >> > Recently I migrated from cmake 2.8.12 to cmake 3.8 and FILE(TIMESTAMP >> ...) >> > behaviour changed. Now it reports symbolic link timestamp instead of >> pointed >> > file timestamp. >> >> Can you track down when that happened? >> >> > I happened in release 3.1.0, back 2014. The commit which changed behaviour > was this: > > https://github.com/Kitware/CMake/commit/9571214e55cb8b86dadb26b6b1d696 > ef488bdd4b > > In source file Source/cmTimestamp.cxx, stat call was replaced by kwsys > ModifiedTime > call. kwsys relies in system function GetFileAttributesExW which do not > resolve symlinks, however stat does (in spite of not being documentented in > MSDN). > > Removing the #ifdef WIN32 clause in ModifiedTime and using stat call > resolves the problem, nevertheless, this change does not resolves > get_filename_compoment symlinks issue in Windows. The problem here is again > in kwsys, which uses system call GetFullPathNameW (which do not resolves > symlinks) instead of GetFinalPathNameByHandleW (which does). > > Despite of being two different commands, I think they are very related in > this issue and the change should be make together. > > >> > patch to fix both get_filename_compoment and FILE(TIMESTAMP ...) >> > >> > What troubles me is that symlink under Windows is a feature introduced >> in >> > Windows Vista and the change for handling them will break Windows XP >> > compatibility. Is this acceptable? >> >> We still support running on XP. If any newer Windows APIs are needed they >> need to be looked up dynamically. Also, behavior changes for existing >> commands >> may need a policy. >> >> > I did not dig into cmake policies development but I am willing to submit a > patch which includes a new policy as soon I can piece it up all together. > > >> See also https://gitlab.kitware.com/cmake/cmake/issues/16926 for >> discussion >> of symbolic link APIs. >> >> -Brad >> > > Manuel. > -- La victoria puede ser creada - Sun Tzu. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Windows symbolic links handling
2017-08-15 16:43 GMT+02:00 Brad King : > On 08/14/2017 06:35 AM, Manu wrote: > > Recently I migrated from cmake 2.8.12 to cmake 3.8 and FILE(TIMESTAMP > ...) > > behaviour changed. Now it reports symbolic link timestamp instead of > pointed > > file timestamp. > > Can you track down when that happened? > > I happened in release 3.1.0, back 2014. The commit which changed behaviour was this: https://github.com/Kitware/CMake/commit/9571214e55cb8b86dadb26b6b1d696ef488bdd4b In source file Source/cmTimestamp.cxx, stat call was replaced by kwsys ModifiedTime call. kwsys relies in system function GetFileAttributesExW which do not resolve symlinks, however stat does (in spite of not being documentented in MSDN). Removing the #ifdef WIN32 clause in ModifiedTime and using stat call resolves the problem, nevertheless, this change does not resolves get_filename_compoment symlinks issue in Windows. The problem here is again in kwsys, which uses system call GetFullPathNameW (which do not resolves symlinks) instead of GetFinalPathNameByHandleW (which does). Despite of being two different commands, I think they are very related in this issue and the change should be make together. > > patch to fix both get_filename_compoment and FILE(TIMESTAMP ...) > > > > What troubles me is that symlink under Windows is a feature introduced in > > Windows Vista and the change for handling them will break Windows XP > > compatibility. Is this acceptable? > > We still support running on XP. If any newer Windows APIs are needed they > need to be looked up dynamically. Also, behavior changes for existing > commands > may need a policy. > > I did not dig into cmake policies development but I am willing to submit a patch which includes a new policy as soon I can piece it up all together. > See also https://gitlab.kitware.com/cmake/cmake/issues/16926 for > discussion > of symbolic link APIs. > > -Brad > Manuel. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Windows symbolic links handling
On 08/14/2017 06:35 AM, Manu wrote: > Recently I migrated from cmake 2.8.12 to cmake 3.8 and FILE(TIMESTAMP ...) > behaviour changed. Now it reports symbolic link timestamp instead of pointed > file timestamp. Can you track down when that happened? > patch to fix both get_filename_compoment and FILE(TIMESTAMP ...) > > What troubles me is that symlink under Windows is a feature introduced in > Windows Vista and the change for handling them will break Windows XP > compatibility. Is this acceptable? We still support running on XP. If any newer Windows APIs are needed they need to be looked up dynamically. Also, behavior changes for existing commands may need a policy. See also https://gitlab.kitware.com/cmake/cmake/issues/16926 for discussion of symbolic link APIs. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Windows symbolic links handling
Hello, Recently I migrated from cmake 2.8.12 to cmake 3.8 and FILE(TIMESTAMP ...) behaviour changed. Now it reports symbolic link timestamp instead of pointed file timestamp. Looking through CMake documentation, it seems I could workaround this issue using the command get_filename_component which documentation states there is a parameter that seems to fix my problem: REALPATH = Full path to existing file with symlinks resolved However, it does not resolves symlinks under Windows. I am working on a patch to fix both get_filename_compoment and FILE(TIMESTAMP ...) and make their behaviour consistent among architectures (under unix systems symlinks are resolve in the refered commands). What troubles me is that symlink under Windows is a feature introduced in Windows Vista and the change for handling them will break Windows XP compatibility. Is this acceptable? Regards. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
