Newer
Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
# Issues we definitely want fixed
https://gitlab.kitware.com/cmake/cmake/-/issues/21475 multi-config install fix
Notes:
This one is clear from Kitware's, it's just a difference between invoking ninja and `cmake --build .`, which should be made to behave the same.
https://gitlab.kitware.com/cmake/cmake/-/issues/24833 better find_package logs
Kitware will discuss which approach is best, log rotation, finding out what is the first cmake run, or something else, and come back to us.
# Work scope and specifics for
https://gitlab.kitware.com/cmake/cmake/-/issues/25790
Kitware will recheck estimate, might have been based on the wrong issue.
# General discussion about windows path issues.
CMake windows path length issues
https://gitlab.kitware.com/cmake/cmake/-/issues/25639
https://gitlab.kitware.com/cmake/cmake/-/issues/25936
https://gitlab.kitware.com/cmake/cmake/-/issues/25797
https://gitlab.kitware.com/cmake/cmake/-/issues/22811
https://gitlab.kitware.com/cmake/cmake/-/issues/22435
https://gitlab.kitware.com/cmake/cmake/-/issues/21337
https://gitlab.kitware.com/cmake/cmake/-/issues/19675
https://gitlab.kitware.com/cmake/cmake/-/issues/18586
https://gitlab.kitware.com/cmake/cmake/-/issues/16485
https://gitlab.kitware.com/cmake/cmake/-/issues/16223
https://gitlab.kitware.com/cmake/cmake/-/issues/15859
Qt one
https://bugreports.qt.io/browse/QTBUG-117413
# My investigation notes
Looked a bit into the windows long path issue
- https://gitlab.kitware.com/cmake/cmake/-/issues/25639
- CMake doesn't support 8.3 file paths, it expands them into long ones
- https://gitlab.kitware.com/cmake/cmake/-/blob/v3.28.1/Source/kwsys/EncodingCXX.cxx#L233-283
- CMake uses a function to use UNC long-path based paths, even if Windows long paths is disabled, but it's not used in all places where paths are processed within CMake
- https://gitlab.kitware.com/cmake/cmake/-/issues/25936
- CMake uses some ChangeDirectory/ CreateProcess Windows API, that seems to not work with long paths even if the tool is made long path aware, needs rechecking
- CMake could use junctions internally like Qt Creator does, but this is a mitigation
- Just using short file paths doesn't seem to be sufficient, due to the CreateProcess issue
- Just fixing the CreateProcess issue is not sufficient because cl.exe is not long path aware
- Using both short paths and a CreateProcess fix might be enough to circumvent cl.exe issue, but CreateProcess fix would be on Windows side
- Qt also has issues due to using FetchContent, which increases the build path substantially
- Sample qml long path
- `C:/Users/frede/Dev/ourapp/build-ourapp-Desktop_Qt_6_5_2_MSVC2019_64bit-Debug/MediaLibrary/qml/MediaLibrary/Controls/Styles/CMakeFiles/ABMediaLibraryControlsStylesQMLplugin.dir/./ABMediaLibraryControlsStylesQMLplugin_MediaLibrary_Controls_StylesPlugin.cpp.obj`
- user path, creator build dir name, qml uri, `CMakeFiles`, plugin target name,` plugintargetnamePlugin.cpp.obj` file
- Setting CMAKE_OBJECT_PATH_MAX to a lower value like 160, with MinGW prevents the generation of hashes for some reason, as opposed to leaving it at 250
- compiler fails to read / write the .d dep file
- Default generated path is
- `-MF CMakeFiles\chapter6-plugins.dir\748d9f7da55b8d98448fb9a66dc59300\chapter6-plugins_qmlcache_loader.cpp.obj.d`
- With value set to 160 it is
- `-MF CMakeFiles\chapter6-plugins.dir\build\Desktop_Qt_6_7_2_MinGW_64_bit-Debug\.rcc\qmlcache\chapter6-plugins_qmlcache_loader.cpp.obj.d`
- It's strange that the `CMakeFiles\chapter6-plugins.dir` part is not elided, and why the default path contains `build\Desktop_Qt_6_7_2_MinGW_64_bit-Debug\` in the name
- Commented some of the findings on qt bug
Notes:
There are repsonse files workarounds employed by cmake for command line length limitations,
but not in all cases. These could be improved on case by case basis.
Integrating the junction idea into cmake proper ,does not seem feasible, too much magic,
all tools and diagnostic messages would refer to junctioned paths.
Unclear how to handle relative paths that go out of source dir reliably.
Idea to improve on the long path for the qml case above would be to get rid of the
`MediaLibrary/qml/MediaLibrary/Controls/Styles` part in the build dir
replace the `ABMediaLibraryControlsStylesQMLplugin.dir/` part with a short hash of the dir,
and the `ABMediaLibraryControlsStylesQMLplugin_MediaLibrary_Controls_StylesPlugin.cpp.obj`
with a hash of the object file name. Perhaps allow customizing the object file name directly
via a source file property.
AP: Alexandru: open an issue on cmake's `qt` project bug tracker project.
Open one task for each work item that we are requesting.