[cmake-developers] Windows symbolic links handling
ianmalcom at gmail.com
Thu Aug 24 03:19:42 EDT 2017
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.
2017-08-16 11:35 GMT+02:00 Manu <ianmalcom at gmail.com>:
> 2017-08-15 16:43 GMT+02:00 Brad King <brad.king at 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
>> > 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:
> 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
> 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
>> > 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
>> 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
>> of symbolic link APIs.
La victoria puede ser creada - Sun Tzu.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cmake-developers