-
Notifications
You must be signed in to change notification settings - Fork 684
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
ghc envs not properly ignored by new-build
#4010
Comments
CC @dcoutts who is captain of this feature. |
Sigh. I guess we can probably work around it for older Cabal Setup.hs scripts by passing |
So, this is because GHC walks up directories until it finds the environment file? Harsh. (You would quite prefer it if you could run Setup script with the environment file unconditionally hidden.) Maybe we could add some sort of environment variable escape hatch to GHC? |
I wonder whether @ezyang is right; using |
@bgamari it could be more explicit with its own new flag, and perhaps that's nice, but it does not seem essential, and certainly not something to hold up 8.0.2 for. The |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
I really like this feature and would want it to get into GHC as soon as possible. I have created a patch for GHC: alexbiehl/ghc@42bbc38 If this approach is okay I will submit this patch to GHCHQ and modify cabal accordingly. |
Hopefully fixes haskell#4010. Parallel to this commit there will be a differential for a new command line flag in GHC: `-no-implicit-package-env`. This flag explicitly disables the implicit search for package.env files in GHC. Before this patch GHC abused the `-hide-all-packages` flag to disable package.env search which lead to the behaviour in haskell#4010.
Hi @alexbiehl, the GHC-level change doesn't really solve the core problem with this bug, because the issue here is old Cabal Setup scripts aren't passing enough flags to environment file enabled GHCs to ensure that the environment file is ignored on certain operations. So really, your fix "accidentally" solves the problem, but only because we never write out environment variables for GHC 8.0 which ships with Cabal 1.24 which doesn't pass |
There appear to be at least two ways to workaround this:
configProgramArgs
| elabSetupScriptCliVersion < mkVersion [1,24,2]
-- workaround for https://github.com/haskell/cabal/issues/4010
= Map.toList $ traceShowId $
Map.insertWith (++) "ghc" ["-hide-all-packages"]
elabProgramArgs
| otherwise = Map.toList elabProgramArgs Note however, that injecting ("/opt/ghc/bin/ghc",["--make","-v","-fbuilding-cabal-package","-O","-static","-dynamic-too","-dynosuf","dyn_o","-dynhisuf","dyn_hi","-outputdir","dist/build","-odir","dist/build","-hidir","dist/build","-stubdir","dist/build","-i","-idist/build","-i.","-idist/build/autogen","-Idist/build/autogen","-Idist/build","-optP-include","-optPdist/build/autogen/cabal_macros.h","-this-unit-id","unbounded-delays-0.1.0.10-a6e8369d7f8cef5fd41d8a3108ced8cc60762d154f538655988622577ad44308"
,"-hide-all-packages","-no-user-package-db","-package-db","/home/test/.cabal/store/ghc-8.0.2/package.db","-package-db","dist/package.conf.inplace","-package-id","base-4.9.1.0","-XHaskell98","Control.Concurrent.Thread.Delay","Control.Concurrent.Timeout","-Wall"
,"-hide-all-packages"]) PS: For a proof of concept, the shell invocation |
This was temporarily disabled via 3033776 due to haskell#4010 but it turns out that we can easily workaround this for older Cabal versions. All we need to do is inject `--ghc-options=-hide-all-packages` into the flags passed to Setup.hs when an old `Cabal` version is detected (this was suggested by @dcoutts in haskell#4010 (comment)) Luckily, `-hide-all-packages` is idempotent in GHC, so we can place it anywhere on the GHC command-line as well as multiple times with the same result.
This was temporarily disabled via 3033776 due to haskell#4010 but it turns out that we can easily workaround this for older Cabal versions. All we need to do is inject `--ghc-options=-hide-all-packages` into the flags passed to Setup.hs when an old `Cabal` version is detected (this was suggested by @dcoutts in haskell#4010 (comment)) Luckily, `-hide-all-packages` is idempotent in GHC, so we can place it anywhere on the GHC command-line as well as multiple times with the same result. This would close haskell#4010
This was temporarily disabled via 3033776 due to haskell#4010 but it turns out that we can easily workaround this for older Cabal versions. All we need to do is inject `--ghc-options=-hide-all-packages` into the flags passed to Setup.hs when an old `Cabal` version is detected (this was suggested by @dcoutts in haskell#4010 (comment)) Luckily, `-hide-all-packages` is idempotent in GHC, so we can place it anywhere on the GHC command-line as well as multiple times with the same result. This would close haskell#4010
This was temporarily disabled via 3033776 due to haskell#4010 but it turns out that we can easily workaround this for older Cabal versions. All we need to do is inject `--ghc-options=-hide-all-packages` into the flags passed to Setup.hs when an old `Cabal` version is detected (this was suggested by @dcoutts in haskell#4010 (comment)) Luckily, `-hide-all-packages` is idempotent in GHC, so we can place it anywhere on the GHC command-line as well as multiple times with the same result. This would close haskell#4010
This was temporarily disabled via 3033776 due to haskell#4010 but it turns out that we can easily workaround this for older Cabal versions. All we need to do is inject `--ghc-options=-hide-all-packages` into the flags passed to Setup.hs (this was suggested by @dcoutts in haskell#4010 (comment)) Luckily, `-hide-all-packages` is idempotent in GHC, so we can place it anywhere on the GHC command-line as well as multiple times with the same result. This would close haskell#4010
This was temporarily disabled via 3033776 due to haskell#4010 but it turns out that we can easily workaround this for older Cabal versions. All we need to do is inject `--ghc-options=-hide-all-packages` into the flags passed to Setup.hs when an old `Cabal` version is detected (this was suggested by @dcoutts in haskell#4010 (comment)) Luckily, `-hide-all-packages` is idempotent in GHC, so we can place it anywhere on the GHC command-line as well as multiple times with the same result. This would close haskell#4010
This was temporarily disabled via 3033776 due to haskell#4010 but it turns out that we can easily workaround this for older Cabal versions. All we need to do is inject `--ghc-options=-hide-all-packages` into the flags passed to Setup.hs when an old `Cabal` version is detected (this was suggested by @dcoutts in haskell#4010 (comment)) Luckily, `-hide-all-packages` is idempotent in GHC, so we can place it anywhere on the GHC command-line as well as multiple times with the same result. This would close haskell#4010 (cherry picked from commit 6fc90eb34259170aa4949d2d127c942899f3351e)
I just ran into an issue which with the help of @ezyang was diagnosed to be caused
by an unlucky combination of custom Setup.hs and a GHC 8.0.2 snapshot with
a not yet updated
Cabal
libThe symptom is the following:
given a trivial package such as
Running
cabal new-build
for the first time succeeds, and creates a file.ghc.environment.x86_64-linux-8.0.1.20161014
with the contentHowever, after resetting the store via e.g.
rm -rf ~/.cabal/store/ghc-8.0.1.20161014/
and removingdist-newstyle
(but leaving the.ghc.env*
file as-is), and re-runningcabal new-build
we now run into a weird & confusing build failure:The text was updated successfully, but these errors were encountered: