-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[service] windows long paths #14216
Comments
@danimtb @uilianries @jcar87 I'm sorry to bother you again. This is another blocking issue for qt (>= 6.4.0). Is there a plan to enable long paths on windows workers ? |
In my experience, the long path registry is only handled by windows applications that support it. If they don't support it, like older versions of VS (as recent as VS2015 didn't support it), that registry key will have no affect. To support it, you need to tell windows that your path is a long path by prependeing the path with For example, the long path you mention at the top: But this could introduce breaking changes because there's a I don't know if this helps you find a solution, but I hope it does as I want to see / use qt 6.4.1 |
Thanks for your feedback, I'm not sure where you expect a crash. As said above, I reproduced the crash on my computer by removing the |
I'm not sure what gives you the impression that I have a crash. Ultimately, what I'm saying is that you can bypass the long paths in certain cases by explicitly prepending the paths with I'm not sure if this can be incorporated in to the solution, or if the solution really is to have the build machines have the |
sorry for my misunderstanding. I was confused and thought you were the author of this message. Thanks for the |
@EricAtORS many thanks for the workaround. 7cafdde just happened to pass on windows ! https://c3i.jfrog.io/c3i/misc/summary.html?json=https://c3i.jfrog.io/c3i/misc/logs/pr/13867/21-configs/windows-visual_studio/qt/6.4.1//summary.json |
is there any point in disabling short_paths? In VS2019 msbuild still can't handle long paths so libraries like ITK/hdf5 can't be built in cases where conan root is long because of user/channel. Is it fixed in VS2022? |
yes, it allows to decompress the source archives, which allows to actually build the package in all the cases where the files with long paths are not used during compilation. |
Is the long path feature enabled on C3I's windows workers ? cf https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#enable-long-paths-in-windows-10-version-1607-and-later
I have the following failure in #13867 (comment):
the error happens in
conan.tools.files.get
, probably because the pathC:\J\w\prod\BuildSingleReference@2/s\c889c3\1\qt6\qtwebengine\src\3rdparty\chromium\third_party\devtools-frontend\src\node_modules\eslint-plugin-lit-a11y\node_modules\eslint-plugin-lit\node_modules\parse5\lib\extensions\location-info\open-element-stack-mixin.js
is too long (261 characters)I can reproduce the error by removing the
short_paths
attribute to the recipe, and removing theLongPathsEnabled
registry valueThe internal stacktrace:
The setup of python proposes to do the
LongPathsEnabled
registry setting at the end:The text was updated successfully, but these errors were encountered: