# 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.