You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Windows absolute paths start with a drive letter. If IS_ABSOLUTE correctly detect them (CMake docs are not very detailed on it), these should work, otherwise it behaves just like before.
Second, there are also root-relative paths, those would need to be properly joined by a string manipulation: leave the old drive letter but replace the rest of the path. If CMake’s IS_ABSOLUTE correctly detects them as relative this will work incorrectly like before. If CMake incorrectly detects root-relative paths as absolute, it will produce incorrect path. (I would expect CMake to work correctly but some Windows user would have to check or inspect the CMake source code.)
Last, there are relative paths and these should work correctly as before (unless CMake detects them as absolute too.)
Using forward slash for directory separators should be fine for most cases. It would be nice to use proper platform-specific ones but this is not a regression.
So in our use case it works for Windows as before (barring a CMake bug), even though I would not expect Windows users to use pkg-config.
Since a merge request adding path manipulations functions have been merged to CMake this month and the fact that it should work in our use case I do not see a point in implementing proper Windows support.
The text was updated successfully, but these errors were encountered:
I wrote a bit about it at nih-at/libzip#213 (comment)
The text was updated successfully, but these errors were encountered: