-
Notifications
You must be signed in to change notification settings - Fork 701
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
Cabal new-build generating insanely long and redundant build PATHS on Windows. #5376
Comments
Does |
But even if there's a workaround, it still seems like a genuine bug that the path is duplicated, no? |
Yeah, I have a PR for that but couldn't figure out why it caused a test to fail on linux and I forgot about it... #4978 Also long paths for Haskell programs are fixed in GHC 8.6, so a cabal-install compiled with 8.6 should work without any workarounds. |
Long paths may be fixed. The response file fix for library search paths, which what @erikd s underlying issue is, won’t be solved in time for 8.6, I believe? |
It depends on when @bgamari wants patches by. I'm trying figured out the
build issues.
…On Mon, Jun 18, 2018, 00:29 Moritz Angermann ***@***.***> wrote:
Long paths may be fixed. The response file fix for library search paths,
which what @erikd <https://github.com/erikd> s underlying issue is, won’t
be solved in time for 8.6, I believe?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#5376 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABH3KUh7ePARmOn2VXr42DhQ3FgR8wVNks5t9uZ1gaJpZM4Uj5ZE>
.
|
Also how is the response files thing Erik'd underlying issue? This ticket is purely about backpack and new-build making a path too long for it to write to with the current platform APIs it's using. It has nothing to do with the underlying compiler and linker because it doesn't get that far. |
You are right that it’s not explicitly mentioned. I believe this came up when we tried to swap cabal in for stack, which kept failing on windows. The exceptionally long paths just made the issue worse. |
I still get long path related errors with cabal new-build using GHC head so I'm not sure if this is completely fixed. |
Such as?
…On Fri, Jul 27, 2018, 09:04 AndreasPK ***@***.***> wrote:
Also long paths for Haskell programs are fixed in GHC 8.6, so a
cabal-install compiled with 8.6 should work without any workarounds.
I still get long path related errors with cabal new-build using GHC head
so I'm not sure if this is completely fixed.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#5376 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABH3KQ7A_GmHQfyLObq3BnuiczL_mcl1ks5uKsmSgaJpZM4Uj5ZE>
.
|
Moving the whole folder into a shallower directory works. Although it's possible that this is caused by the library issue discussed above? Either way I still see errors with cabal using 8.6(HEAD) and long paths.
|
Right, that's not cabal failing but gccc, we have a ticket for that. The
patch explicitly mentioned ghc is not excluded from MAX_PATH because of the
use of gnu utilities. That's going to take some time to patch
…On Fri, Jul 27, 2018, 10:00 AndreasPK ***@***.***> wrote:
Building executable 'aeson-benchmark-compare' for aeson-benchmarks-0..
[1 of 1] Compiling Main ( AesonEncode.hs, C:\ghc\msys64\home\Andi\bench_script\lib_bench\aeson\aeson_allCalls\dist-vanilla\build\x86_64-windows\ghc-8.7.20180718\aeson-benchmarks-0\x\aeson-benchmark-aeson-encode\build\aeson-benchmark-aeson-encode\aeson-benchmark-aeson-encode-tmp\Main.o )
[1 of 1] Compiling Main ( CompareWithJSON.hs, C:\ghc\msys64\home\Andi\bench_script\lib_bench\aeson\aeson_allCalls\dist-vanilla\build\x86_64-windows\ghc-8.7.20180718\aeson-benchmarks-0\x\aeson-benchmark-compare-with-json\build\aeson-benchmark-compare-with-json\aeson-benchmark-compare-with-json-tmp\Main.o )
[ 1 of 10] Compiling Options ( Options.hs, C:\ghc\msys64\home\Andi\bench_script\lib_bench\aeson\aeson_allCalls\dist-vanilla\build\x86_64-windows\ghc-8.7.20180718\aeson-benchmarks-0\x\aeson-benchmark-auto-compare\build\aeson-benchmark-auto-compare\aeson-benchmark-auto-compare-tmp\Options.o )
Assembler messages:
Fatal error: can't create C:\\ghc\\msys64\\home\\Andi\\bench_script\\lib_bench\\aeson\\aeson_allCalls\\dist-vanilla\\build\\x86_64-windows\\ghc-8.7.20180718\\aeson-benchmarks-0\\x\\aeson-benchmark-auto-compare\\build\\aeson-benchmark-auto-compare\\aeson-benchmark-auto-compare-tmp\\Options.o: No such file or directory
[2 of 7] Compiling Compare.JsonBuilder ( Compare\JsonBuilder.hs, C:\ghc\msys64\home\Andi\bench_script\lib_bench\aeson\aeson_allCalls\dist-vanilla\build\x86_64-windows\ghc-8.7.20180718\aeson-benchmarks-0\x\aeson-benchmark-compare\build\aeson-benchmark-compare\aeson-benchmark-compare-tmp\Compare\JsonBuilder.o )
`gcc.exe' failed in phase `Assembler'. (Exit code: 1)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#5376 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABH3KanJrbX41JorOheFiwIrB5IRT9U0ks5uKtargaJpZM4Uj5ZE>
.
|
Ultimately there's nothing |
But thanks for the reminder @AndreasPK! I'll try to look at the remaining Linux failure this weekend. |
I think this has been fixed already, there are no directories in
I only see it with GHC 8.10.7. I will preemptively close this issue. Feel free to re-open if you disagree. |
I'm trying to https://github.com/input-output-hk/cardano-sl on Windows in AppVeyor. Unfortunately Cardano SL is a large project and using Stack we have been continuously bumping up against the Windows path length limitations.
Trying
cabal new-build
as an alternative to stack we run into the Windows path length issue in a different place. From the AppVeyor output, it seemscabal new-build
is installing stuff in:a path with one hell of a lot of redundancy. That path should at least be shortened to something like:
The text was updated successfully, but these errors were encountered: