Skip to content
Snippets Groups Projects
Select Git revision
  • master default
1 result
Blame Permalink
kitware_03_09_2024_upstream_contract.md 4.61 KiB

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.