-
Notifications
You must be signed in to change notification settings - Fork 698
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
Regression in 3.10 cabal build
: the extra-prog-path
ends up first in the PATH, shadowing build-tools
#9756
Comments
cabal build
: the extra-prog-path
ends up first in the PATH, shadowing build-tools
I found the original issue now that I tracked it to
The problem was originally introduced in: There is a PR by @gbaz claiming to fix the problem: But possibly the following PR touching the same lines undid the fix: ATTN: @jasagredo @fendor (Classic whack-a-mole game, if you ask me. Only more tests in the suite can save us from evil here...) |
Maybe a simple list of paths (that can either be pre- or appended) does not satisfy all the different requirements.
The entries could then be weighted differently for different purposes. E.g. when trying to run a build-tool, consider the paths coming from build-tool installations first. What error diagnostics concerns (I spent almost 5 hours in this bug hunt), it could be good if cabal, on error, displays all versions of the build tool it founds on directories contained in the PATH, not just the first one it rejected. E.g. it could say:
If there was be the provenance for each path, a real good diagnostics of the problem could be given. |
In general, the order, from least precedence to most precedence should be
|
Sorry for not noticing this in my PR. I don't usually use Indeed I am pretty sure I prepend the I am currently a bit swamped with other stuff so I might not be able to work on this in the short term. The solution you are proposing looks appealing, however I don't know if there will be many different cases where we can take advantage of the provenance. Shouldn't |
Just for clarity
These paths are not relevant. They might be in the system PATH but that is all, they won't be included in the effective PATH just by their own. |
We must consider the path to the installed build-tool before the path to existing versions of the build tool in paths such as `extra-prog-path` or in the system path. This was previously fixed by haskell#8972 but undone by haskell#9527. This also renames `appendProgramSearchPath` to `prependProgramSearchPath` to describe correctly what that function does. Fixes haskell#9756
We must consider the path to the installed build-tool before the path to existing versions of the build tool in paths such as `extra-prog-path` or in the system path. This was previously fixed by haskell#8972 but undone by haskell#9527. This also renames `appendProgramSearchPath` to `prependProgramSearchPath` to describe correctly what that function does. Fixes haskell#9756
We must consider the path to the installed build-tool before the path to existing versions of the build tool in paths such as `extra-prog-path` or in the system path. This was previously fixed by haskell#8972 but undone by haskell#9527. This also renames `appendProgramSearchPath` to `prependProgramSearchPath` to describe correctly what that function does. Fixes haskell#9756
We must consider the path to the installed build-tool before the path to existing versions of the build tool in paths such as `extra-prog-path` or in the system path. This was previously fixed by haskell#8972 but undone by haskell#9527. This also renames `appendProgramSearchPath` to `prependProgramSearchPath` to describe correctly what that function does. Fixes haskell#9756
We must consider the path to the installed build-tool before the path to existing versions of the build tool in paths such as `extra-prog-path` or in the system path. This was previously fixed by haskell#8972 but undone by haskell#9527. This also renames `appendProgramSearchPath` to `prependProgramSearchPath` to describe correctly what that function does. Fixes haskell#9756
We must consider the path to the installed build-tool before the path to existing versions of the build tool in paths such as `extra-prog-path` or in the system path. This was previously fixed by haskell#8972 but undone by haskell#9527. This also renames `appendProgramSearchPath` to `prependProgramSearchPath` to describe correctly what that function does. Fixes haskell#9756
We must consider the path to the installed build-tool before the path to existing versions of the build tool in paths such as `extra-prog-path` or in the system path. This was previously fixed by #8972 but undone by #9527. This also renames `appendProgramSearchPath` to `prependProgramSearchPath` to describe correctly what that function does. Fixes #9756 (cherry picked from commit 84c30c2)
We must consider the path to the installed build-tool before the path to existing versions of the build tool in paths such as `extra-prog-path` or in the system path. This was previously fixed by haskell#8972 but undone by haskell#9527. This also renames `appendProgramSearchPath` to `prependProgramSearchPath` to describe correctly what that function does. Fixes haskell#9756
My
installdir
is set to~/.cabal/bin
in my~/.cabal/config
file. I havealex-3.4.0.1
installed there.I also have set
extra-prog-path: ~/.cabal/bin
set in my config.I am trying to build this project which requires a newer
alex
:Foo/Lex.x
contains some lexer definition to be processed with alex.With cabal-3.10.2.1 and current master I am getting this error:
Building succeeds with cabal-3.8 and older.
Running with -v3 I see that the
extra-prog-path
ends up before the path for alex-3.5.1.0 in the PATH component of the environment.cabal exec
instead calls the correctalex
for this project:I checked a bit the source ofcabal
and it seems thatcabal exec
does not receives theinstalldir
, so it cannot interfere here.The source files to reproduce it (on my system) are at https://github.com/andreasabel/cabal-bug-build-tool .
However, I could not reproduce the problem on the machines provided by GHA (see the workflow file for my attempt).There, the PATH is correct:> ("PATH","/home/runner/.cabal/store/ghc-9.8.2/alex-3.5.1.0-e-alex-075f98fe20ffc7a07799cfa46f51c24d5236956a51dccba7409f8f308610de2a/bin:/home/runner/.cabal/binUpdate: I could now reproduce it, supplying the
extra-prog-path
. It ends up first in the PATH:https://github.com/andreasabel/cabal-bug-build-tool/actions/runs/8099486076/job/22135333052#step:10:1936
CI proves that it is a regression in 3.10, as 3.8 succeeds there as well: https://github.com/andreasabel/cabal-bug-build-tool/actions/runs/8099613006
The text was updated successfully, but these errors were encountered: