Cannot install pango with new-build when using local copy of gtk2hs-buildtools #5164
Comments
|
I've created https://github.com/RyanGlScott/cabal-gh5164, which minimizes this bug. To use it: |
|
In contrast, here's what happens with |
|
I believe this to be a long-standing issue w/ local packages, because we construct a So the solution would be either to
|
|
Out of curiosity, is there an environment variable that I can set manually to work around this issue? |
|
Sure, it's documented here: So you need to set an env-var named And for reference, this here is the place were e.g. cabal/cabal-install/Distribution/Client/CmdRun.hs Lines 226 to 256 in abaf365 |
|
Thanks, that's very helpful. A related question: does |
|
For the time being, I'm finding myself having to hardcode the directory in which the Obviously, this is quite ugly, and won't scale if your |
Maybe for (non-local) "inplace" packages (I'd have to check), but certainly not for local "inplace" ones. |
|
Note that $ more ./setup-lib/.stack-work/dist/x86_64-linux/Cabal-2.0.1.0/build/autogen/Paths_setup_lib.hs
{-# LANGUAGE CPP #-}
{-# OPTIONS_GHC -fno-warn-missing-import-lists #-}
{-# OPTIONS_GHC -fno-warn-implicit-prelude #-}
module Paths_setup_lib (
version,
getBinDir, getLibDir, getDynLibDir, getDataDir, getLibexecDir,
getDataFileName, getSysconfDir
) where
import qualified Control.Exception as Exception
import Data.Version (Version(..))
import System.Environment (getEnv)
import Prelude
#if defined(VERSION_base)
#if MIN_VERSION_base(4,0,0)
catchIO :: IO a -> (Exception.IOException -> IO a) -> IO a
#else
catchIO :: IO a -> (Exception.Exception -> IO a) -> IO a
#endif
#else
catchIO :: IO a -> (Exception.IOException -> IO a) -> IO a
#endif
catchIO = Exception.catch
version :: Version
version = Version [0,1] []
bindir, libdir, dynlibdir, datadir, libexecdir, sysconfdir :: FilePath
bindir = "/home/rgscott/Documents/Hacking/Haskell/sandbox/cabal-gh5164/.stack-work/install/x86_64-linux/lts-10.7/8.2.2/bin"
libdir = "/home/rgscott/Documents/Hacking/Haskell/sandbox/cabal-gh5164/.stack-work/install/x86_64-linux/lts-10.7/8.2.2/lib/x86_64-linux-ghc-8.2.2/setup-lib-0.1-8hekJdedMBc9fTEHUxKQOX"
dynlibdir = "/home/rgscott/Documents/Hacking/Haskell/sandbox/cabal-gh5164/.stack-work/install/x86_64-linux/lts-10.7/8.2.2/lib/x86_64-linux-ghc-8.2.2"
datadir = "/home/rgscott/Documents/Hacking/Haskell/sandbox/cabal-gh5164/.stack-work/install/x86_64-linux/lts-10.7/8.2.2/share/x86_64-linux-ghc-8.2.2/setup-lib-0.1"
libexecdir = "/home/rgscott/Documents/Hacking/Haskell/sandbox/cabal-gh5164/.stack-work/install/x86_64-linux/lts-10.7/8.2.2/libexec/x86_64-linux-ghc-8.2.2/setup-lib-0.1"
sysconfdir = "/home/rgscott/Documents/Hacking/Haskell/sandbox/cabal-gh5164/.stack-work/install/x86_64-linux/lts-10.7/8.2.2/etc"
getBinDir, getLibDir, getDynLibDir, getDataDir, getLibexecDir, getSysconfDir :: IO FilePath
getBinDir = catchIO (getEnv "setup_lib_bindir") (\_ -> return bindir)
getLibDir = catchIO (getEnv "setup_lib_libdir") (\_ -> return libdir)
getDynLibDir = catchIO (getEnv "setup_lib_dynlibdir") (\_ -> return dynlibdir)
getDataDir = catchIO (getEnv "setup_lib_datadir") (\_ -> return datadir)
getLibexecDir = catchIO (getEnv "setup_lib_libexecdir") (\_ -> return libexecdir)
getSysconfDir = catchIO (getEnv "setup_lib_sysconfdir") (\_ -> return sysconfdir)
getDataFileName :: FilePath -> IO FilePath
getDataFileName name = do
dir <- getDataDir
return (dir ++ "/" ++ name) |
|
@RyanGlScott this looks a lot like what the old |
|
Indeed, I can confirm that this works with sandboxes as well. This is an annoying enough issue (I experience it several times per day) that I'm inclined to figure out how to fix it. |
|
Well, first we'd need to agree which of the two variants mentioned in my comment #5164 (comment) we want to pursue (there's a reason we didn't just go w/ the obsolete PS: related #4120 and #4558 (comment) (but I don't think that's the discussion I was thinking of) |
I'm +1 on this idea, what are the arguments against? |
|
I'd be in favor of that as well. |
|
@23Skidoo Can't think of any showblocker arguments against either. |
|
Great! Now the question arises of how to implement this. I'm a neophyte when it comes to the |
https://github.com/haskell/cabal/blob/master/cabal-install/Distribution/Client/ProjectBuilding.hs#L930 is the place where |
|
A question for the -- Warning: This operation is NOT thread-safe, because current
-- environment is a process-global concept.This is pretty worrying—if we're going to be building things in parallel (which is often the case), it means that we don't have a particularly strong guarantee that when we build a particular component, Note that Thoughts? |
|
Setting the vars should be fine when using the external setup method (running a compiled setup script) or the self-exec setup method ( Though you're right about |
Fix #5164 by overriding environment variables when new-building custom Setups
I'm experiencing this issue with both:
To trigger the issue:
Note that this bug will not be triggered if you have installed
gtk2hs-buildtools-0.13.3.1previously usingcabal install, as that will cause~/.cabal/share/x86_64-linux-ghc-8.2.2/gtk2hs-buildtools-0.13.3.1/hierarchyGen/Hierarchy.chs.templateto have been created.Moreover, this bug does not occur if
gtk2hs-buildtools-0.13.3.1is not put intocabal.projectand is instead downloaded from Hackage.I suspect the issue may have something to do with this line of code in
gtk2hs-buildtools-0.13.3.1:The text was updated successfully, but these errors were encountered: