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 <ianmal...@gmail.com>: > > > 2017-08-15 16:43 GMT+02:00 Brad King <brad.k...@kitware.com>: > >> 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
