danielg / cabal-helper Goto Github PK

View Code? Open in Web Editor NEW

24.0 9.0 38.0 868 KB

Give Haskell development tools access to Cabal project environment.

License: Apache License 2.0

Haskell 94.97% Shell 5.03%

haskell-development haskell-tooling

cabal-helper's People

Contributors

Stargazers

Watchers

cabal-helper's Issues

Can not build 0.8.0.0 with stack

When I run stack init --solver, I get

Using resolver: lts-10.3
Using compiler: ghc-8.2.2
Asking cabal to calculate a build plan...
Trying with packages from lts-10.3 as hard constraints...
Could not parse cabal-install errors:

>>>> Cabal errors begin
cabal.EXE:
E:\nosave\Projects\Haskell\StackPackages\cabal-helper-0.8.0.0\tests\bkpregex\bkpregex.cabal:
This package requires at least Cabal version 2.0
<<<< Cabal errors end

CallStack (from HasCallStack):
  error, called at src/Stack\Solver.hs:130:25 in stack-1.6.3-F6YVX3qh2MsHZufmhdWM8J:Stack.Solver

The problem is present on both ubuntu and win10 with stack-1.6.3

What is the correct approach to build cabal-helper here?

Error compiling cabal-helper at runtime using stack-2.1.3 due to two simultaneous cabal versions

When trying to run the haskell-ide-engine unit test suite in appveyor i've got several warnings and errors cause it is compiled against two versions of cabal but i think i got this error running the test suite in azure as well.
I can't reproduce it in my local windows machine.
Appveyor build: https://ci.appveyor.com/project/jneira/haskell-ide-engine/builds/27821597?fullLog=true
There are several warnings like:

In file included from <command-line>:10:0: error: 
C:/Users/appveyor/AppData/Local/Temp/ghc2460_0/ghc_2.h:7:0: warning: "VERSION_Cabal" redefined
 #define VERSION_Cabal "2.4.1.0"

And errors:

C:\\Users\appveyor\Local Settings\Cache\cabal-helper\cabal-helper0.9.0.0-Cabal2.4.0.1.build\CabalHelper\Shared\Common.hs:42:1: error:
    Ambiguous module name `Distribution.PackageDescription.Parsec':
      it was found in multiple packages: Cabal-2.4.0.1 Cabal-2.4.1.0
   |
42 | import qualified Distribution.PackageDescription.Parsec as P
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Thanks in advance!

Could not find $libexecdir/cabal-helper-wrapper

I'm using GHC 7.10.3 with Stack 1.0.4.3. Project builds successfully with stack and some extra-deps in stack.yaml. Also stack repl works.

When I call ghc-mod it gives this error:
Warning: Specified resolver could not satisfy all dependencies. Some external packages have been added as dependencies.
You can suppress this message by removing it from stack.yaml

ghc-mod: Could not find $libexecdir/cabal-helper-wrapper

If you are a developer set the environment variable
`cabal_helper_libexecdir' to override $libexecdir1. The following will
work in the cabal-helper source tree:

$ export cabal_helper_libexecdir=$PWD/dist/build/cabal-helper-wrapper

If you don't know what I'm talking about something went wrong with your
installation. Please report this problem here:

https://github.com/DanielG/cabal-helper/issues

Build and test with GHC 8.6 (0.8-series)

It does not appear that cabal-helper is tested using GHC 8.6 (from the gitlab-ci.yml file). When building the latest release (though I haven't tested the latest commit) with GHC 8.6, I get

Building library for cabal-helper-0.8.1.2..
[1 of 4] Compiling CabalHelper.Shared.InterfaceTypes ( src/CabalHelper/Shared/InterfaceTypes.hs, dist/build/CabalHelper/Shared/InterfaceTypes.o )            
[2 of 4] Compiling CabalHelper.Shared.Sandbox ( src/CabalHelper/Shared/Sandbox.hs, dist/build/CabalHelper/Shared/Sandbox.o )                                 
[3 of 4] Compiling Paths_cabal_helper ( dist/build/autogen/Paths_cabal_helper.hs, dist/build/Paths_cabal_helper.o )
[4 of 4] Compiling Distribution.Helper ( lib/Distribution/Helper.hs, dist/build/Distribution/Helper.o )

lib/Distribution/Helper.hs:383:3: error:
    • Could not deduce (Control.Monad.Fail.MonadFail m)
        arising from a do statement
        with the failable pattern ‘[Just (ChResponseVersion pkgName
                                                            pkgVer)]’
      from the context: MonadQuery m
        bound by the type signature for:
                   getPackageId :: forall (m :: * -> *).
                                   MonadQuery m =>
                                   m (String, Version)
        at lib/Distribution/Helper.hs:381:1-51
      Possible fix:
        add (Control.Monad.Fail.MonadFail m) to the context of
          the type signature for:
            getPackageId :: forall (m :: * -> *).
                            MonadQuery m =>
                            m (String, Version)
    • In a stmt of a 'do' block:
        [Just (ChResponseVersion pkgName pkgVer)] <- readHelper
                                                       ["package-id"]
      In the expression:
        do [Just (ChResponseVersion pkgName pkgVer)] <- readHelper
                                                          ["package-id"]
           return (pkgName, pkgVer)
      In the second argument of ‘(>>=)’, namely
        ‘\ QueryEnv {..}
           -> do [Just (ChResponseVersion pkgName pkgVer)] <- readHelper [...]
                 return (pkgName, pkgVer)’
    |
383 |   [ Just (ChResponseVersion pkgName pkgVer) ] <- readHelper [ "package-id" ]                                                                           
    |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Cabal helper ties to install 2.4.0.1 even if 2.4.1.0 is installed

I'm fighting with vs-code for Haskell setup. Between plenty of issues I've found that cabal-helper is installing 2.4.0.1 cabal even if cabal-static 2.4.1.0-1 is installed on my Arch

Error loading projects with `source-repository-package`

If you add a source-repository-package stanza in a cabal.project of a simple project, the load in haskell-ide-engine fails with:

cd d:\dev\ws\haskell\cabal-test; cabal v2-build --with-ghc=D:\bin\stack\x86_64-windows\ghc-8.6.5\bin\ghc.exe --with-ghc-pkg=D:\bin\stack\x86_64-windows\ghc-8.6.5\bin\ghc-pkg.exe --with-haddock=D:\bin\stack\x86_64-windows\ghc-8.6.5\bin\haddock.exe --project-file=d:\dev\ws\haskell\cabal-test\cabal.project --builddir=d:\dev\ws\haskell\cabal-test\dist-newstyle --dry-run all
Build profile: -w ghc-8.6.5 -O1
In order, the following would be built (use -v for more details):
 - my-source-repository-package-1.0.0.0 (lib) (first run)
 - cabal-test-0.1.0.0 (lib) (configuration changed)
 - cabal-test-0.1.0.0 (exe:cabal-test) (configuration changed)
hie-wrapper: panic! planPackages.mkPackage: Got non-unpacked package src!

The error is thrown here:

cabal-helper/src/CabalHelper/Compiletime/Program/CabalInstall.hs

Line 279 in c20981c

_ -> panicIO "planPackages.mkPackage: Got non-unpacked package src!"

The error message seems to be logical but i supposed the load of projects with source-repository-package would be supported.

Original hie issue: haskell/haskell-ide-engine#1621

add cabal-helper to Stackage Nightly

It would be nice to add the package to Stackage.

With the current release, for Nightly I get:

cabal-plan-0.5.0.0 is out of bounds for:

cabal-helper-0.8.1.2 (>=0.3.0.0 && < 0.5). @DanielG. Used by: library, executable, test-suite

ghc-8.6.5 is out of bounds for:

cabal-helper-0.8.1.2 (>=7.8 && < 8.5). @DanielG. Used by: test-suite

pretty-show-1.9.5 (Grandfathered dependencies) is out of bounds for:

cabal-helper-0.8.1.2 (>=1.8.1 && < 1.9). @DanielG. Used by: executable, test-suite

semigroupoids-5.3.2 (Edward Kmett [email protected] @ekmett) is out of bounds for:

cabal-helper-0.8.1.2 (==5.2.*). @DanielG. Used by: library

template-haskell-2.14.0.0 is out of bounds for:

cabal-helper-0.8.1.2 (>=2.7.0.0 && < 2.14). @DanielG. Used by: executable, test-suite

temporary-1.3 (Grandfathered dependencies) is out of bounds for:

cabal-helper-0.8.1.2 (>=1.2.1 && < 1.3). @DanielG. Used by: executable, test-suite

Reintroduced restrictive upper bounds

process-1.4.2.0 is out of bounds for:

cabal-helper-0.7.1.0 (>=1.1.0.1 && < 1.3). Daniel Gröber [email protected] @DanielG. @DanielG

template-haskell-2.11.0.0 is out of bounds for:

cabal-helper-0.7.1.0 (>=2.7.0.0 && < 2.11). Daniel Gröber [email protected] @DanielG. @DanielG

Failure to locate binary while installing with Stack

When I install cabal-helper with Stack, I get this error:

Couldn't find executable cabal-helper-wrapper in directory <project-directory>/.stack-work/install/x86_64-linux/lts-8.5/8.0.2/bin/

However, the binary is there, under .stack-work/install/x86_64-linux/lts-8.5/8.0.2/libexec/x86_64-linux-ghc-8.0.2/cabal-helper-0.7.3.0/cabal-helper-wrapper, so if I issue

cp .stack-work/install/x86_64-linux/lts-8.5/8.0.2/libexec/x86_64-linux-ghc-8.0.2/cabal-helper-0.7.3.0/cabal-helper-wrapper .stack-work/install/x86_64-linux/lts-8.5/8.0.2/bin/

and run stack install cabal-helper again, I get

Copying from <project-directory>/.stack-work/install/x86_64-linux/lts-8.5/8.0.2/bin/cabal-helper-wrapper to /home/ser/.local/bin/cabal-helper-wrapper

Copied executables to /home/ser/.local/bin/:
- cabal-helper-wrapper

I'm not sure whether this is an issue with Stack or cabal-helper, but cabal-helper is the only package I've seen that exhibits this behavior.

I execute all commands from the directory where https://github.com/input-output-hk/cardano-sl is cloned. Its latest .cabal file is here. My stack --version.

See also the mirror of this issue in the Stack repository.

Support --with-cabal-pkg-db in library and use it in ghc-mod

See DanielG/ghc-mod#725 (comment)

EXCEPTION: browse:ghc-mod: Could not find $libexecdir/cabal-helper-wrapper

neco-ghc: EXCEPTION: browse:ghc-mod: Could not find $libexecdir/cabal-helper-wrapper                                                                                                                               
neco-ghc: If you are a developer set the environment variable                                                                                                                                                      
neco-ghc: `cabal_helper_libexecdir' to override $libexecdir[1]. The following will                                                                                                                                 
neco-ghc: work in the cabal-helper source tree:                                                                                                                                                                    
neco-ghc:     $ export cabal_helper_libexecdir=$PWD/dist/build/cabal-helper-wrapper                                                                                                                                
neco-ghc: [1]: /usr/lib/x86_64-linux-ghc-8.0.2/cabal-helper-0.7.3.0                                                                                                                                                
neco-ghc: If you don't know what I'm talking about something went wrong with your                                                                                                                                  
neco-ghc: installation. Please report this problem here:                                                                                                                                                           
neco-ghc:     https://github.com/DanielG/cabal-helper/issues

:NecoGhcDiagnostics
Current filetype: haskell                                                                                                                                                                                          
ghc-mod is executable: 1                                                                                                                                                                                           
omnifunc: necoghc#omnifunc                                                                                                                                                                                         
neocomplete.vim: 0                                                                                                                                                                                                 
neocomplcache.vim: 0                                                                                                                                                                                               
YouCompleteMe: 0                                                                                                                                                                                                   
vimproc.vim: not installed                                                                                                                                                                                         
ghc-mod: 5.7.0.0                                                                                                                                                                                                   
Imported modules: Prelude                                                                                                                                                                                          
Number of symbols in Prelude: 0

Hi,
Unfortunately I have no idea what this means, so i don't really know what else to report.

> nvim --version
NVIM v0.2.2
Build type: RelWithDebInfo
LuaJIT 2.0.4
Compilation: /usr/bin/cc -g -O2 -fdebug-prefix-map=/build/neovim-0hqwXz/neovim-0.2.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DDISABLE_LOG -Wdate-time -D_FORTIFY_SOURCE=2 -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -O2 -g -DMIN_LOG_LEVEL=3 -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -I/build/neovim-0hqwXz/neovim-0.2.2/build/config -I/build/neovim-0hqwXz/neovim-0.2.2/src -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/build/neovim-0hqwXz/neovim-0.2.2/build/src/nvim/auto -I/build/neovim-0hqwXz/neovim-0.2.2/build/include
Compiled by [email protected]

Features: +acl +iconv +jemalloc +tui 
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

Run :checkhealth for more info

> cabal --version
cabal-install version 1.24.0.2
compiled using version 1.24.2.0 of the Cabal library

> stack --version
Version 1.6.5, Git revision 24ab0d6ff07f28276e082c3ce74dfdeb1a2ca9e9 (5514 commits) x86_64 hpack-0.20.0


> cat /etc/issue
Ubuntu 17.10 \n \l

Consider replace temporary private lib with a common stanza to avoid cabal bug

To avoid a infamous cabal bug with private libs: see haskell/cabal#6483 duplicated of haskell/cabal#6211
Workarounds:
- Using a separated store-dir for cabal build and cabal v2-install seems to avoid the issue
- Wipe out the entire store-dir (ugh) or remove cabal-plan dirs from it and run cabal-store-check --repair
@DanielG i could prepare a pr if you agree, including a TODO to restore the private lib when the bug is fixed

Replace use of localPkgDescr

We use localPkgDescr in a couple of places, we probably shouldn't.

See:

Release 0.7.3.0 not in GitHub

Hackage has a release that's not on GitHub.

Setup.hs needs access to sandbox!

We need to take that into account when returning options for it, though it's a very uncommon configuration so I'll probably not fix it until someone asks for it hint hint

temporary 1.2.1 is required

The cabal file specifies >= 1.2.0.4, but the use of getCanonicalTemporaryDirectory here means that 1.2.1 is required, as that is the version where it was added.

Make Setup.hs target use Cabal from sandbox when that's available

Remove build/run-time dependency on cabal-install

See #40 and related discussion.

Downloading the release tarball and latest cabal metadata using a HTTP library or wget/curl shouldn't be very hard to implement.

Add cabal to build-tool-depends

@DanielG wrote in haskell/haskell-ide-engine#372 :

The dependency on the cabal executable is declared in Setup.hs but that only applies to Cabal < 2 so I guess we should probably add cabal to build-tool-depends actually.

Missing build-tool-depends on Hackage for 0.8.1.0

We switched to cabal-version: 2.0.0.0 and build-type: simple for 0.8.1.0 which sets cabal-install into a mode where it considers dependencies on components seperately. Hence cabal-helper-wrapper is no longer installed when depending only on the cabal-helper library.

Adding build-tool-depends: cabal-helper:cabal-helper-wrapper to the library component seems to fix this though "build-tool" is a bit of a misnormer here because we actually need the executable at runtime. Not sure if this is the proper thing to do in this case or not.

@hvr Hackage doesn't seem to let me add a build-tool-depends for 0.8.1.0 after the fact can could you add that for me?

PS: What's the proper procedure for asking for help from Hackage Trustees as a package maintainer? I don't really want to spam @hvr with these things exclusively :)

Error building with cabal and ghc-8.8.1 in windows

Hi! Testing the recent ghc-8.8.1 support in win i've got a solver error:

PS D:\dev\ws\haskell\cabal-helper> cabal build -w ghc-8.8.1 --minimize-conflict-set
Resolving dependencies...
cabal.exe: Could not resolve dependencies:
[__0] trying: cabal-helper-1.0.0.0 (user goal)
[__1] trying: unix-compat-0.5.2 (dependency of cabal-helper)
[__2] trying: unix-compat:-old-time
[__3] next goal: time (dependency of cabal-helper)
[__3] rejecting: time-1.9.3/installed-1.9..., time-1.9.3, time-1.9.2,
time-1.9.1, time-1.9 (conflict: unix-compat -old-time => time>=1.0 && <1.9)
[__3] trying: time-1.8.0.4
[__4] next goal: directory (dependency of cabal-helper)
[__4] rejecting: directory-1.3.3.2/installed-1.3... (conflict: time =>
base>=4.7 && <4.13, directory => base==4.13.0.0/installed-4.1...)
[__4] trying: directory-1.3.5.0
[__5] next goal: base (dependency of cabal-helper)
[__5] rejecting: base-4.13.0.0/installed-4.1... (conflict: time => base>=4.7
&& <4.13)
[__5] rejecting: base-4.12.0.0, base-4.11.1.0, base-4.11.0.0, base-4.10.1.0,
base-4.10.0.0, base-4.9.1.0, base-4.9.0.0, base-4.8.2.0, base-4.8.1.0,
base-4.8.0.0, base-4.7.0.2, base-4.7.0.1, base-4.7.0.0, base-4.6.0.1,
base-4.6.0.0, base-4.5.1.0, base-4.5.0.0, base-4.4.1.0, base-4.4.0.0,
base-4.3.1.0, base-4.3.0.0, base-4.2.0.2, base-4.2.0.1, base-4.2.0.0,
base-4.1.0.0, base-4.0.0.0, base-3.0.3.2, base-3.0.3.1 (constraint from
non-upgradeable package requires installed instance)
[__5] fail (backjumping, conflict set: base, cabal-helper, time)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, directory, cabal-helper, time,
unix-compat, unix-compat:old-time

The error trying to build hie with ghc-8.8.1 support was:

PS D:\dev\ws\haskell\haskell-ide-engine> cabal build -w ghc-8.8.1 --minimize-conflict-set
Resolving dependencies...
cabal.exe: Could not resolve dependencies:
[__0] trying: haskell-ide-engine-1.0.0.0 (user goal)
[__1] trying: directory-1.3.3.2/installed-1.3... (dependency of
haskell-ide-engine)
[__2] trying: time-1.9.3/installed-1.9... (dependency of directory)
[__3] trying: cabal-helper-1.0.0.0 (dependency of haskell-ide-engine)
[__4] trying: unix-compat-0.5.2 (dependency of cabal-helper)
[__5] rejecting: unix-compat:-old-time (conflict: directory =>
time==1.9.3/installed-1.9..., unix-compat -old-time => time>=1.0 && <1.9)
[__5] rejecting: unix-compat:+old-time (conflict:
directory==1.3.3.2/installed-1.3..., unix-compat +old-time =>
directory==1.1.*)
[__5] fail (backjumping, conflict set: directory, unix-compat,
unix-compat:old-time)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: cabal-helper, haskell-ide-engine,
base, unix-compat, directory, time, unix-compat:old-time

Ambiguous occurance `lookupInstalledPackageId`

The issue is caused by the absence of upper bounds and unqualified imports.

drets@MBP ~/s/a/s/N/MQTT> ghc-mod check Gateway.hs 
[1 of 5] Compiling CabalHelper.Types ( CabalHelper/Types.hs, /home/drets/.ghc-mod/cabal-helper/CabalHelper/Types.o )
[2 of 5] Compiling CabalHelper.Common ( CabalHelper/Common.hs, /home/drets/.ghc-mod/cabal-helper/CabalHelper/Common.o )
[3 of 5] Compiling CabalHelper.Sandbox ( CabalHelper/Sandbox.hs, /home/drets/.ghc-mod/cabal-helper/CabalHelper/Sandbox.o )
[4 of 5] Compiling CabalHelper.Licenses ( CabalHelper/Licenses.hs, /home/drets/.ghc-mod/cabal-helper/CabalHelper/Licenses.o )

CabalHelper/Licenses.hs:53:18: error:
    Ambiguous occurrence 'lookupInstalledPackageId'
    It could refer to either 'Distribution.Simple.PackageIndex.lookupInstalledPackageId',
                             imported from 'Distribution.Simple.PackageIndex' at CabalHelper/Licenses.hs:24:1-39
                          or 'CabalHelper.Licenses.lookupInstalledPackageId',
                             defined at CabalHelper/Licenses.hs:38:1

CabalHelper/Licenses.hs:74:10: error:
    Ambiguous occurrence 'lookupInstalledPackageId'
    It could refer to either 'Distribution.Simple.PackageIndex.lookupInstalledPackageId',
                             imported from 'Distribution.Simple.PackageIndex' at CabalHelper/Licenses.hs:24:1-39
                          or 'CabalHelper.Licenses.lookupInstalledPackageId',
                             defined at CabalHelper/Licenses.hs:38:1
ghc-mod: readCreateProcess: /home/drets/.stack/snapshots/x86_64-linux-nix/lts-6.1/7.10.3/libexec/cabal-helper-wrapper "--with-ghc=ghc" "--with-ghc-pkg=ghc-pkg" "--with-cabal=cabal" "/home/drets/src/arachne" "/home/drets/src/arachne/dist" "package-db-stack" "entrypoints" "source-dirs" "ghc-options" "ghc-src-options" "ghc-pkg-options" "ghc-merged-pkg-options" "ghc-lang-options" "licenses" "flags" "config-flags" "non-default-config-flags" "compiler-version" (exit 1): failed

Fix suggestion for `-i` flags and the `cabal-preprocessors` test

Hi @DanielG

I've been struggling to setup ghc-mod on Arch Linux with dynamic-only GHC 8.2 (Cabal-2.0.1.0, cabal-install-2.0.0.1, no stackage) for a while now. There's only a partial success, and I've identified a couple of issues; one of which seems to have the root cause contained within these lines:

cabal-helper/src/CabalHelper/Runtime/Main.hs

Lines 500 to 506 in b81f78a

    
             componentsMap lbi v distdir $ \c clbi bi -> 
        
                    let 
        
           #if CH_MIN_VERSION_Cabal(2,0,0) 
        
                      outdir = componentBuildDir lbi clbi 
        
           #else 
        
                      outdir = componentOutDir lbi c 
        
           #endif

The #if looks wrong to me; perhaps it should be inverted. Was the real intention to use componentOutDir on Cabal >= 2.0 (and componentBuildDir otherwise) perhaps?..

I base the "looks wrong" conclusion on a single assumption, that cabal-helper ... ghc-options should output about the same cmdline as cabal repl --verbose. On current master, this is not the case.

Let's see the dist structure of a trivial package:

dist
├── build
│   └── foo-pkg
│       ├── autogen
│       │   ├── cabal_macros.h
│       │   └── Paths_foo_pkg.hs
│       └── foo-pkg-tmp
├── cabal-config-flags
├── package.conf.inplace
│   ├── package.cache
│   └── package.cache.lock
├── setup-config
├── setup-config.ghc-mod.cabal-components
├── setup-config.ghc-mod.package-options
└── setup-config.ghc-mod.resolved-components

foo-pkg-tmp is the componentOutDir if I'm not mistaken. cabal repl passes that to ghc:

[foo-pkg] cabal repl --verbose
Using internal setup method with build-type Simple and args:
["repl","--verbose=2","--builddir=dist"]
/usr/bin/ghc-pkg init dist/package.conf.inplace
creating dist/build/foo-pkg
creating dist/build/foo-pkg/autogen
creating dist/build/foo-pkg/autogen
Preprocessing executable 'foo-pkg' for foo-pkg-0.1.0.0..
creating dist/build/foo-pkg
creating dist/build/foo-pkg/foo-pkg-tmp
/usr/bin/ghc --interactive
    -fbuilding-cabal-package
    -O0
    -outputdir dist/build/foo-pkg/foo-pkg-tmp
    -odir dist/build/foo-pkg/foo-pkg-tmp
    -hidir dist/build/foo-pkg/foo-pkg-tmp
    -stubdir dist/build/foo-pkg/foo-pkg-tmp
    -i
    -idist/build/foo-pkg/foo-pkg-tmp
    -i.
    -idist/build/foo-pkg/autogen
    -idist/build/global-autogen
    -Idist/build/foo-pkg/autogen
    -Idist/build/global-autogen
    -Idist/build/foo-pkg/foo-pkg-tmp
    -optP-include
    -optPdist/build/foo-pkg/autogen/cabal_macros.h
    -hide-all-packages
    -Wmissing-home-modules
    -package-db dist/package.conf.inplace
    -package-id base-4.10.1.0
    -package-id comonad-5.0.3-1wQLfIXhDc15HcgpkWgfSP
    -XHaskell2010 ./Main.hs -dynamic
GHCi, version 8.2.2: http://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/ulidtko/.config/dotfiles/HOME/ghci
[1 of 1] Compiling Main             ( Main.hs, interpreted )
Ok, one module loaded.

(I've added some layout for legibility.)

But cabal-helper in b81f78a does something different (due to the lines I quoted above):

[foo-pkg] ghc-mod -vvvvv check Main.hs
info: Found Cabal project at: /home/ulidtko/src/ghc-mod/test/foo-pkg
info: Using Cabal project at: /home/ulidtko/src/ghc-mod/test/foo-pkg
DEBUG: setup configuration is out of date
DEBUG: reconfiguring Cabal project
[1 of 4] Compiling CabalHelper.Shared.Common ( /home/ulidtko/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.0.1.0.build/CabalHelper/Shared/Common.hs, /home/ulidtko/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.0.1.0.build/CabalHelper/Shared/Common.o )
[2 of 4] Compiling CabalHelper.Shared.InterfaceTypes ( /home/ulidtko/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.0.1.0.build/CabalHelper/Shared/InterfaceTypes.hs, /home/ulidtko/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.0.1.0.build/CabalHelper/Shared/InterfaceTypes.o )
[3 of 4] Compiling CabalHelper.Shared.Sandbox ( /home/ulidtko/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.0.1.0.build/CabalHelper/Shared/Sandbox.hs, /home/ulidtko/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.0.1.0.build/CabalHelper/Shared/Sandbox.o )
[4 of 4] Compiling Main             ( /home/ulidtko/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.0.1.0.build/CabalHelper/Runtime/Main.hs, /home/ulidtko/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.0.1.0.build/Main.o )
Linking /home/ulidtko/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.0.1.0 ...
DEBUG: regenerating cache: /home/ulidtko/src/ghc-mod/test/foo-pkg/dist/setup-config.ghc-mod.cabal-components (cache missing or unreadable)
DEBUG: writing memory cache: /home/ulidtko/src/ghc-mod/test/foo-pkg/dist/setup-config.ghc-mod.cabal-components
DEBUG: resolveEntrypoint:
       ["-i","-idist/build/foo-pkg","-i.","-idist/build/foo-pkg/autogen","-idist/build/global-autogen","-Idist/build/foo-pkg/autogen","-Idist/build/global-autogen","-Idist/build/foo-pkg","-optP-include","-optPdist/build/foo-pkg/autogen/cabal_macros.h"]
DEBUG: resolveEntrypoint: []
DEBUG: making sure autogen files exist
DEBUG: autogen files out of sync
DEBUG: writing Cabal autogen files
DEBUG: resolvedComponentsCache: files changed: none
DEBUG: resolveGmComponent:
       ["-optP-include","-optPdist/build/autogen/cabal_macros.h"]
DEBUG: resolveGmComponent:
       ["-i","-idist/build/foo-pkg","-i.","-idist/build/foo-pkg/autogen","-idist/build/global-autogen","-Idist/build/foo-pkg/autogen","-Idist/build/global-autogen","-Idist/build/foo-pkg","-optP-include","-optPdist/build/foo-pkg/autogen/cabal_macros.h","-XHaskell2010","-optP-include","-optPdist/build/autogen/cabal_macros.h"]
DEBUG: regenerating cache: dist/setup-config.ghc-mod.resolved-components (cache missing or unreadable)
DEBUG: writing memory cache: dist/setup-config.ghc-mod.resolved-components
VOMIT: Initializing GHC session with following options:
    "-fbuilding-cabal-package"
    "-O"
    "-outputdir" "dist/build/foo-pkg"
    "-odir" "dist/build/foo-pkg"
    "-hidir" "dist/build/foo-pkg"
    "-stubdir" "dist/build/foo-pkg"
    "-i"
    "-idist/build/foo-pkg"
    "-i."
    "-idist/build/foo-pkg/autogen"
    "-idist/build/global-autogen"
    "-Idist/build/foo-pkg/autogen"
    "-Idist/build/global-autogen"
    "-Idist/build/foo-pkg"
    "-optP-include"
    "-optPdist/build/foo-pkg/autogen/cabal_macros.h"
    "-hide-all-packages"
    "-Wmissing-home-modules"
    "-package-id" "base-4.10.1.0"
    "-package-id" "comonad-5.0.3-1wQLfIXhDc15HcgpkWgfSP"
    "-XHaskell2010" "-dynamic" "-Wno-missing-home-modules" "-O0"

I think this supposedly ought to match the cabal repl cmdline.

Anyhow, this quick-n-dirty patch:

-#if CH_MIN_VERSION_Cabal(2,0,0)
-           outdir = componentBuildDir lbi clbi
-#else
            outdir = componentOutDir lbi c
-#endif

-- fixes the cmdline; it also fixes the cabal-preprocessors spec test on Cabal 2.0. I'm able to replicate locally the test failure on master; applying quick-n-dirty fixes that test.

For completeness, I can see that @alanz fixes the cabal-preprocessors test in #46, although in a different way. I think that fix will work, but it will also mask the real bug (which is the incorrect version check for componentOutDir/componentBuildDir) which causes the issue in the first place.

I'm not sending this as a PR just yet -- simply because it'd be way too hard, and too irrelevant for my real goal, to test this under Cabal 1.24.

Am intrigued to hear if this is indeed a real catch (or if I'm totally off the track here). In the positive case, I'll gladly save you a dozen keystrokes by making a pull request.

Make execution of cached runtime compiled executable more robust

We should try to recompile the runtime-main exe if the cached one fails to exec.

It could be that the user upgraded their distribution and older soversions baked into the binary are no longer available.

We also don't namespace by architecture so home directory sharing isn't going to work seamlessly. We should do that.

Relax runtime Cabal dependency

According to Cabal's docs minor versions should also have compatible dist/setup-config format so when installing a copy of Cabal we should constrain only the major version instead of pointing at one specific version.

https://github.com/DanielG/cabal-helper/blob/master/CabalHelper/Wrapper.hs#L326

bump upper bounds of Cabal to 1.23 ?

Is there a reason why the dependencies of the cabal-helper library, the cabal-helper-wrapper executable and the spec testsuite cannot be bumped to 1.23? I.e. to include rather than disallow 1.23 as an upper bound.

Look for Cabal in sandbox paths

DanielG/ghc-mod#478 (comment)

cabal-helper is not compatible with "no-reinstall cabal"

In its current form, "no-reinstall Cabal" does not export inplacePackageId, which is used by cabal-helper here.

Transition to using cabal-install's show-buid-info (or similar)

See here: haskell/cabal#2771

Change license to Apache2

Hey guys. I would like to change cabal-helper's license from GPLv3+ to Apache2 to allow ghcide (formerly hie-core) to use it. @bubba, @wz1000, @alanz

If you don't have any objections please just say you agree below so we have this on public record, thanks.

cabal-helper-0.3.4.0 test suite shouldn't access $HOME

The test suite fails in NixOS, http://hydra.cryp.to/build/805079/log/raw, because builds do not have $HOME configured. It's probably a bad idea to rely on that path to accessible for a test suite run. Instead, I'd recommend using $TMPDIR or something like that.

Tag 0.8.0.0 release in git (v0.8.0.0)

I don't see a tag for the 0.8.0.0 release yet which appears to be uploaded to Hackage already1.

$ git ls-remote [email protected]:DanielG/cabal-helper.git v0.7.2.0 | wc -l
1

$ git ls-remote [email protected]:DanielG/cabal-helper.git v0.8.0.0 | wc -l
0

cabal-helper error with a custom cabal `store-dir`

when compiling at runtime cabal-helper creates a package environment included the path to the default store-dir (C:\Users\user\AppData\Roaming\cabal\store\ghc-8.6.5\package.db) in its ghc package environment in C:\Users\user\Local Settings\Cache\cabal-helper\ghc-8.6.5.package-envs\Cabal-3.0.0.0.package-env.
if you change the value of store-dir in the glocal cabal config (to avoid max paths issues in windows f.e.) that location doesnt exists
it causes the calls to cabal-helper fails with

Loaded package environment from C:\Users\user\Local Settings\Cache\cabal-helper\ghc-8.6.5.package-envs\Cabal-3.0.0.0.package-env
ghc.exe: can't find a package database at C:\Users\user\AppData\Roaming\cabal\store\ghc-8.6.5\package.db

changing manually the path in Cabal-3.0.0.0.package-env to the actual one makes it work

cabal-helper fails on ghc-mod commands for project

I'm not sure when it was broken, but ghc-mod now fails when executed within project directory.
box is newly created project with cabal init, configured and installed, and no sandbox there

PS D:\users\voidex\Documents\Projects\box> ghc-mod check .\src\Test.hs
cabal-helper-wrapper.exe: C:\Users\Alexandr\AppData\Local\Temp\cabal-helper7856\CabalHelper\Main.hs: commitBuffer: invalid argument (invalid character)
ghc-mod.exe: readCreateProcess: C:\Users\Alexandr\AppData\Roaming\cabal\cabal_0P5q9UpHEkV3g6HCMgHTaZ\cabal-helper-wrapper.exe "D:\\users\\voidex\\Documents\\Projects\\box\\dist" "entrypoints" "source-dirs" "ghc-options" "ghc-src-options" "ghc-pkg-options" "ghc-merged-pkg-options" "ghc-lang-options" "--with-ghc=ghc" "--with-ghc-pkg=ghc-pkg" "--with-cabal=cabal" (exit 1): failed

Error checking file in Spacemacs Haskell Mode

When attempting to load a file in spacemacs haskell mode I get the following error http://lpaste.net/157693

The thing is the file they are refrencing doesnt exist on my computer.

cabal-helper tries to configure a component named package:setup that does not exist.

Hello,

we ran into an issue in another project over here haskell/haskell-ide-engine#1638 (comment)

is this something that can be fixed in cabal-helper ?

cabal-helper can't install Cabal-3.0.0.0 at runtime in windows

Testing @fendor hie branch that uses cabal-helper master with hie-bios: https://github.com/fendor/haskell-ide-engine/tree/cabal-helper-helper (pr mpickering/haskell-ide-engine#26)
In windows 7
Log with CABAL_HELPER_DEBUG=1:

D:\bin\Programs\stack\x86_64-windows\ghc-8.6.5\bin\ghc.exe --numeric-version
=> 8.6.5

cabal --numeric-version
=> 3.0.0.0

using helper compiled with Cabal from v2-build package-env C:\Users\user\Local Settings\Cache\cabal-helper\ghc-8.6.5.package-envs\Cabal-3.0.0.0.package-env
helper exe does not exist, compiling C:\Users\user\Local Settings\Cache\cabal-helper\cabal-helper-1.0.0.0--Cabal-3.0.0.0--c82cca47f9974858fe3c009873651f1e71ad14c20be7c4b4932a9ed554ec09d2.build\cabal-helper
cabal-helper: Installing a private copy of Cabal because we couldn't
find the right version anywhere on your system. You can set the environment
variable CABAL_HELPER_DEBUG=1 to see where we searched.

Note that this installation might take a little while but it will only
happen once per Cabal library version used in your build-plans.

If you want to avoid this automatic installation altogether install
version 3.0.0.0 of the Cabal library manually, either using cabal or your
system package manager. With cabal you can use the following command:
    $ cabal install Cabal --constraint "Cabal == 3.0.0.0"

FYI the build products and cabal-helper executable cache are all in the
following directory, you can simply delete it if you think something
is broken :
    C:\Users\user\Local Settings\Cache\cabal-helper
Please do report any problems you encounter.

Installing Cabal 3.0.0.0 ...
cabal --numeric-version
=> 3.0.0.0

cd C:\TEMP\; cabal --no-require-sandbox v2-install --with-compiler=D:\bin\Programs\stack\x86_64-windows\ghc-8.6.5\bin\ghc.exe --with-hc-pkg=D:\bin\Programs\stack\x86_64-windows\ghc-8.6.5\bin\ghc-pkg.exe '--package-env=C:\Users\user\Local Settings\Cache\cabal-helper\ghc-8.6.5.package-envs\Cabal-3.0.0.0.package-env' --lib Cabal-3.0.0.0
Resolving dependencies...
Up to date
Distribution\Simple\GHC.hs:1959:5-56: Non-exhaustive patterns in Just ghcPkgProg

No C:\Users\user\Local Settings\Cache\cabal-helper is even created (and if it exists it doesnt create ghc-8.6.5.package-envs inside)

hsinspect requirements

Hello!

I would like to make use of cabal-helper to solve some problems that I am encountering when writing https://gitlab.com/tseenshe/hsinspect I hope you don't mind me creating a thread here for discussion (this is not a feature request or bug report as such).

I would like to have a launcher that can choose which one of multiple binaries to launch based on the current ghc version. e.g. say the user (or more likely the text editor behind the scene) installs hsinspect-ghc-8.4.4 and hsinspect-ghc-8.6.5 and their current project is using ghc-8.4.4 then I would like to invoke hsinspect-ghc-8.4.4. I can do this with a hack using cabal v2-exec ghc and parsing the output string but that is tedious and I am interested in alternatives. Note that actually installing applications this way is not easy because --program-suffix doesn't work during v2-install 🤷‍♂️
Inside my program I would like to be able to provide a FilePath (the source file I am inspecting) and receive back a DynFlags that is populated with anything relevant from the .cabal and cabal.project / cabal.project.local. Most importantly are: default language, language extensions, compiler options. i.e. inferDynFlags :: FilePath -> IO DynFlags. If you don't want to depend on ghc then I would be ok with Strings and LangExt.Extensions and similar.
I would like to be able to generate a packagedb that matches the most recent v2-build (or implied build from a v2-run or v2-install) and set the correct environment variable, so that when I use the ghc api it is set appropriately. Note: I want to include the current package -inplace even if it is not compilable. Ideally this would take the package and specific phase (application / library / test) into account, which would be far superior to the generated cabal .ghc.env.* files. i.e. setupGhcEnv :: FilePath -> IO ().
Without adding any more dependencies 😄 It is very important to me that I do not have a large depednency graph. I had hoped to be zero dependency (only installed things) to simplify and speed up the installation process (I was considering having my app be a single file that is compiled manually by directly invoking ghc!) So adding a dependency on cabal-helper is already a big step for me.
hie-bios integration. Ideally I would like to be able to abstract these things across all build tools. I understand that hie-bios plans to do that but I'd like to see it working reliably for cabal-install first. If hie-bios is going to have lots of big dependencies (e.g. on hpack or stack / yaml libraries) then that's a show stopper but perhaps I could put it behind a flag. // @mpickering

cabal-helper 0.8.0.2 miss dependencies in nixos

Hi, I was trying to install cabal-helper, using channel nixos-unstable and nix-shell.
And error happens:

these derivations will be built:
  /nix/store/6lf07ww2670mq85q59kbmkj1hqjrd8im-cabal-helper-0.8.0.2.drv
  /nix/store/l9zyy5gwlvh5wvgn8i80pbwbp4grpbka-ghc-8.4.3-with-packages.drv
building '/nix/store/6lf07ww2670mq85q59kbmkj1hqjrd8im-cabal-helper-0.8.0.2.drv'...
setupCompilerEnvironmentPhase
Build with /nix/store/yc8an71h8cah8w6fw0xykjxl68a8j1h7-ghc-8.4.3.
ignoring (possibly broken) abi-depends field for packages
ignoring (possibly broken) abi-depends field for packages
unpacking sources
unpacking source archive /nix/store/27g5a92f4s32mif60j426gd663iyrqvx-cabal-helper-0.8.0.2.tar.gz
source root is cabal-helper-0.8.0.2
setting SOURCE_DATE_EPOCH to timestamp 1518192504 of file cabal-helper-0.8.0.2/tests/UnitTests.hs
patching sources
Replace Cabal file with edited version from http://hackage.haskell.org/package/cabal-helper-0.8.0.2/revision/1.cabal.
compileBuildDriverPhase
setupCompileFlags: -package-db=/tmp/nix-build-cabal-helper-0.8.0.2.drv-0/setup-package.conf.d -j1 -threaded
[1 of 1] Compiling Main             ( Setup.hs, /tmp/nix-build-cabal-helper-0.8.0.2.drv-0/Main.o )
Linking Setup ...
configuring
configureFlags: --verbose --prefix=/nix/store/1f0612gn5apjs3m5vfcl12yssx5q9x11-cabal-helper-0.8.0.2 --libdir=$prefix/lib/$compiler --libsubdir=$pkgid --docdir=/nix/store/icpsmz8zcdgjciraa4i45gvr841isk95-cabal-helper-0.8.0.2-doc/share/doc/cabal-helper-0.8.0.2 --with-gcc=gcc --package-db=/tmp/nix-build-cabal-helper-0.8.0.2.drv-0/package.conf.d --ghc-option=-j1 --disable-split-objs --enable-library-profiling --profiling-detail=all-functions --disable-profiling --enable-shared --disable-coverage --enable-static --disable-executable-dynamic --disable-tests --enable-library-vanilla --enable-library-for-ghci --ghc-option=-split-sections --extra-lib-dirs=/nix/store/3cnh0n698w18l5g933wrx22zvkhcj8ik-ncurses-6.1/lib --extra-lib-dirs=/nix/store/bi9nx8f8kl8apgd544hkx2dsvlvr4zix-gmp-6.1.2/lib
Using Parsec parser
Warning: cabal-helper.cabal:125:3: The field "scope" is available since Cabal
[2,0]
Configuring cabal-helper-0.8.0.2...
CallStack (from HasCallStack):
  die', called at ./Distribution/Simple/Configure.hs:958:20 in Cabal-2.2.0.1-302vnEvwKgd3FEKLIV6HbI:Distribution.Simple.Configure
  configureFinalizedPackage, called at ./Distribution/Simple/Configure.hs:462:12 in Cabal-2.2.0.1-302vnEvwKgd3FEKLIV6HbI:Distribution.Simple.Configure
  configure, called at ./Distribution/Simple.hs:596:20 in Cabal-2.2.0.1-302vnEvwKgd3FEKLIV6HbI:Distribution.Simple
  confHook, called at ./Distribution/Simple/UserHooks.hs:67:5 in Cabal-2.2.0.1-302vnEvwKgd3FEKLIV6HbI:Distribution.Simple.UserHooks
  configureAction, called at ./Distribution/Simple.hs:178:19 in Cabal-2.2.0.1-302vnEvwKgd3FEKLIV6HbI:Distribution.Simple
  defaultMainHelper, called at ./Distribution/Simple.hs:115:27 in Cabal-2.2.0.1-302vnEvwKgd3FEKLIV6HbI:Distribution.Simple
  defaultMain, called at Setup.hs:11:8 in main:Main
Setup: Encountered missing dependencies:
Cabal >=1.14 && <1.26 || ==2.0.*,
template-haskell >=2.7.0.0 && <2.13,
temporary >=1.2.0.4 && <1.3

builder for '/nix/store/6lf07ww2670mq85q59kbmkj1hqjrd8im-cabal-helper-0.8.0.2.drv' failed with exit code 1
cannot build derivation '/nix/store/l9zyy5gwlvh5wvgn8i80pbwbp4grpbka-ghc-8.4.3-with-packages.drv': 1 dependencies couldn't be built
error: build of '/nix/store/l9zyy5gwlvh5wvgn8i80pbwbp4grpbka-ghc-8.4.3-with-packages.drv' failed

I guess I should report here.

cabal-helper-wrapper and stack

If I install cabal-helper using a straightforward cabal install it autogens the value in Paths_cabal_helper.hs as

libexecdir = "/home/alanz/.cabal/libexec"

It is found for normal ghc-mod operations.

If I blow away the .cabal/libexec directory, and run ghc-mod from a stack install, the libexec path still gets set as above, even though the install directory is now in .stack-work, and the other paths in that file properly reflect this.

The particular case shows up in https://travis-ci.org/alanz/HaRe/builds/74307616

This is low priority for me, now I know what the problem is I can work around it for travis, but probably needs to be fixed some time.

Errors in hie unit test suite involving cabal-helper since 04c2d34

In the process of testing #93 and #97 in hie i got several errors running the hie unit test suite with
cabal test :unit-test --test-options="--match CabalHelper"
All tests involving stack as build tool (but no cabal) fails with:

1) CabalHelper, cabal-helper spec, cradle discovery and loading, dummy filepath, finds none-cradle, stack repo
       uncaught exception: IOException of type NoSuchThing
       D:\ws\haskell\haskell-ide-engine\test\testdata\cabal-helper\simple-stack\.stack-work\dist\e626a42b\setup-config: openFile:
does not exist (No such file or directory)

I've checked that effectively the D:\ws\haskell\haskell-ide-engine\test\testdata\cabal-helper\simple-stack\.stack-work\dist dir does not exist
Then i've started to bisect cabal-helper commits since the hackage released version and i've found that the commit that triggers the error is 04c2d34 (1c0f2e8 works fine but it does not create the dist folders)

(NOTE: it would be great to have hackage releases/revisions tagged in github, to help diagnose those kind of bugs)

Restrictive upper bounds on pretty-show and temporary

These bounds are a little too strict: pretty-show >=1.8.1 && <1.9, temporary >=1.2.1 && <1.3. Pretty sure they can be bumped.

Test suite fails to build

http://hydra.cryp.to/build/1099729/nixlog/2/raw has a full build log, but the pertinent bit is:

CabalHelper/Main.hs:206:43:
    Couldn't match expected type ‘NubListR
                                    (InstalledPackageId,
                                     PackageId,
                                     Distribution.PackageDescription.ModuleRenaming)’
                with actual type ‘[a1]’
    In the ‘ghcOptPackages’ field of a record
    In the expression:
      res
        {ghcOptPackageDBs = withPackageDB lbi,
         ghcOptHideAllPackages = Flag True,
         ghcOptPackages = nub $ ghcOptPackages res}
    In an equation for ‘res'’:
        res'
          = res
              {ghcOptPackageDBs = withPackageDB lbi,
               ghcOptHideAllPackages = Flag True,
               ghcOptPackages = nub $ ghcOptPackages res}

CabalHelper/Main.hs:206:49:
    Couldn't match expected type ‘[a1]’
                with actual type ‘NubListR
                                    (InstalledPackageId,
                                     PackageId,
                                     Distribution.PackageDescription.ModuleRenaming)’
    In the second argument of ‘($)’, namely ‘ghcOptPackages res’
    In the ‘ghcOptPackages’ field of a record

CabalHelper/Main.hs:378:48:
    Couldn't match expected type ‘NubListR
                                    (InstalledPackageId,
                                     PackageId,
                                     Distribution.PackageDescription.ModuleRenaming)’
                with actual type ‘[a0]’
    In the ‘ghcOptPackages’ field of a record
    In the expression:
      opts {ghcOptPackages = nub $ ghcOptPackages opts}
    In an equation for ‘nubPackageFlags’:
        nubPackageFlags opts
          = opts {ghcOptPackages = nub $ ghcOptPackages opts}

CabalHelper/Main.hs:378:54:
    Couldn't match expected type ‘[a0]’
                with actual type ‘NubListR
                                    (InstalledPackageId,
                                     PackageId,
                                     Distribution.PackageDescription.ModuleRenaming)’
    In the second argument of ‘($)’, namely ‘ghcOptPackages opts’
    In the ‘ghcOptPackages’ field of a record

Clarify libexec not found error message

The word "developer" is ambiguous in the error message and should be clarified. See atom-haskell-archive/haskell-ghc-mod#214 where this apparently caused confusion.

Test suite has undeclared dependency on 'cabal-install'

Citing from http://hydra.cryp.to/build/1533267/nixlog/1/raw:

Running 1 test suites...
Test suite spec: RUNNING...
spec: cabal: rawSystem: runInteractiveProcess: exec: does not exist (No such file or directory)
Test suite spec: FAIL

Nix builds include only those packages that the Cabal declares as a required build input, and since there's no build-tools: cabal attribute associated with the test suite, no cabal binary is available in the chroot environment that compiles this package.

Non-exaustive Pattern Match

Looks like there is a non-exhaustive pattern match here:
https://github.com/DanielG/cabal-helper/blob/master/lib/Distribution/Helper.hs#L603

This is causing the following error for me using HIE through the Haskell Language Server extension in vscode:
hie-wrapper: user error (Pattern match failure in do expression at lib\Distribution\Helper.hs:603:7-22)

The error is preceeded by the following, which might be the cause of an empty list.

'stty' is not recognized as an internal or external command,
operable program or batch file.

Full HIE log:

2020-01-04 21:37:03.1001694 [ThreadId 3] - run entered for hie-wrapper(hie-wrapper) Version 1.0.0.0, Git revision a8c156b8a12d03c9eb4a23174eaac1eb9725eff1 (3539 commits) x86_64 ghc-8.6.5
2020-01-04 21:37:03.1021712 [ThreadId 3] - Current directory:d:\source\demo-project
2020-01-04 21:37:03.1021712 [ThreadId 3] - Operating system:mingw32
2020-01-04 21:37:03.1031721 [ThreadId 3] - Cabal-Helper found these projects: ["ProjLocStackYaml {plStackYaml = \"d:\\\\source\\\\demo-project\\\\stack.yaml\"}"]
2020-01-04 21:37:03.1041732 [ThreadId 3] - These projects have the build tools installed: ["ProjLocStackYaml {plStackYaml = \"d:\\\\source\\\\demo-project\\\\stack.yaml\"}"]
2020-01-04 21:37:03.1041732 [ThreadId 3] - Cabal-Helper dirs: ["d:\\source\\demo-project","d:\\source\\demo-project\\File.hs"]
'stty' is not recognized as an internal or external command,
operable program or batch file.
'stty' is not recognized as an internal or external command,
operable program or batch file.
hie-wrapper: user error (Pattern match failure in do expression at lib\Distribution\Helper.hs:603:7-22)
[Error - 9:37:04 PM] Connection to server got closed. Server will not be restarted.

I realize that this issue might stem from HIE, but I wanted to make you aware of the ungraceful exit due to the failed pattern matching.

Make wrapper executable API backwards compatible

Just changing ChComponentName to support Cabal HEAD turned out to be a bad idea. If we have executables still linked against cabal-helper-0.6.* they will fail with a read error now even though they would otherwise still work since Cabal HEAD isn't out yet anyways.

I think the best way to fix this is to change the name of the wrapper executable to include an API version number, this way cabal will not overwrite the old version.

Runtime errors using stack and ghc-8.6.4/ghc-8.4.4 on windows

Error running the test suite with stack and ghc-8.6.4

Catched in the test suite of haskell-ide-engine: https://dev.azure.com/jneira/haskell-ide-engine/_build/results?buildId=434
With other ghc versions it works fine.
Maybe it can affect the normal use of hie (pending of testing)
Error:

src\CabalHelper\Compiletime\CompPrograms.hs:95:5: 
  1) CabalHelper, cabal-helper spec, cradle discovery, dummy filepath, finds none-cradle, stack repo, dummy filepath
       uncaught exception: IOException of type UserError
       user error (Pattern match failure in do expression at src\CabalHelper\Compiletime\CompPrograms.hs:95:5-17)

cabal-helper/src/CabalHelper/Compiletime/CompPrograms.hs

Lines 92 to 99 in 1c0f2e8

    
           createProgSymlink :: FilePath -> FilePath -> IO () 
        
           createProgSymlink bindir target 
        
             | [exe] <- splitPath target = do 
        
               Just exe_path <- findExecutable exe 
        
               createSymbolicLink exe_path (bindir </> takeFileName target) 
        
             | otherwise = do 
        
               cwd <- getCurrentDirectory 
        
               createSymbolicLink (cwd </> target) (bindir </> takeFileName target)

Can't build on Windows due to unix dependency

I'm building the current HEAD and it fails because you can't build unix on Windows. Is there a workaround there?

linker error with ghc-7.10.2 os X 10.10

I am trying to install ghc-mod with ghc-7.10.2 on os x 10.10. All goes fine until cabal-helper-0.3.8.0 (I've tried a build that uses 0.3.6.0 as well and the same thing happens) and I get a linker error:

VSUX7zckgKqJjgw -Wl,-rpath,/Applications/ghc-7.10.2.app/Contents/lib/ghc-7.10.2/binar_IvYoLp9H6Xy3zEH13MmZwd -Wl,-rpath,/Applications/ghc-7.10.2.app/Contents/lib/ghc-7.10.2/rts -Wl,-rpath,/Applications/ghc-7.10.2.app/Contents/lib/ghc-7.10.2/bytes_6elQVSg5cWdFrvRnfxTUrH -Wl,-rpath,/Applications/ghc-7.10.2.app/Contents/lib/ghc-7.10.2/conta_LKCPrTJwOTOLk4OU37YmeN -Wl,-rpath,/Users/adam/Development/haskell/ghc-mod/.cabal-sandbox/7.10.2/lib/x86_64-osx-ghc-7.10.2/datad_CezeH4zzjVt9K2zxHCqYv5 -Wl,-rpath,/Users/adam/Development/haskell/ghc-mod/.cabal-sandbox/7.10.2/lib/x86_64-osx-ghc-7.10.2/datad_CgDdtafiXY68XlqDb5IqXw -Wl,-rpath,/Users/adam/Development/haskell/ghc-mod/.cabal-sandbox/7.10.2/lib/x86_64-osx-ghc-7.10.2/datad_6bNp7ygtVUW3TbxeJU4Irf -Wl,-rpath,/Users/adam/Development/haskell/ghc-mod/.cabal-sandbox/7.10.2/lib/x86_64-osx-ghc-7.10.2/datad_2eq6fuwf8Tk14CtKGZXhB5 -Wl,-rpath,/Users/adam/Development/haskell/ghc-mod/.cabal-sandbox/7.10.2/lib/x86_64-osx-ghc-7.10.2/datad_IOUiWbb0av0L7SSTC6QavD -Wl,-rpath,/Users/adam/Development/haskell/ghc-mod/.cabal-sandbox/7.10.2/lib/x86_64-osx-ghc-7.10.2/datad_D3fIWe3ExBN6VISnKTEJV3 -Wl,-rpath,/Applications/ghc-7.10.2.app/Contents/lib/ghc-7.10.2/deeps_LbCWUlehDDeLxurARKDH5o -Wl,-rpath,/Applications/ghc-7.10.2.app/Contents/lib/ghc-7.10.2/direc_KowvXytSqazBcvN7MGpFtg -Wl,-rpath,/Users/adam/Development/haskell/ghc-mod/.cabal-sandbox/7.10.2/lib/x86_64-osx-ghc-7.10.2/dlist_CWmYfPEEnFvAl2glQ7oHsq -Wl,-rpath,/Users/adam/Development/haskell/ghc-mod/.cabal-sandbox/7.10.2/lib/x86_64-osx-ghc-7.10.2/excep_8GsEeHgaIks3pVGk6GaELJ -Wl,-rpath,/Applications/ghc-7.10.2.app/Contents/lib/ghc-7.10.2/filep_KsGE6pHE5eZHSN90ZVax6A -Wl,-rpath,/Applications/ghc-7.10.2.app/Contents/lib/ghc-7.10.2/ghcpr_8TmvWUcS1U1IKHT0levwg3 -Wl,-rpath,/Applications/ghc-7.10.2.app/Contents/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS -Wl,-rpath,/Users/adam/Development/haskell/ghc-mod/.cabal-sandbox/7.10.2/lib/x86_64-osx-ghc-7.10.2/mtl_KMpng31YRYc5JfMWFZ3FCU -Wl,-rpath,/Users/adam/Development/haskell/ghc-mod/.cabal-sandbox/7.10.2/lib/x86_64-osx-ghc-7.10.2/oldlo_D6X1KPq5Sui5XjrHMwvFwK -Wl,-rpath,/Applications/ghc-7.10.2.app/Contents/lib/ghc-7.10.2/prett_7UQTOB05U7lIYPkFOVraeR -Wl,-rpath,/Applications/ghc-7.10.2.app/Contents/lib/ghc-7.10.2/proce_FLTz0SLwyG6LJUpZ52HjkU -Wl,-rpath,/Users/adam/Development/haskell/ghc-mod/.cabal-sandbox/7.10.2/lib/x86_64-osx-ghc-7.10.2/stm_C1kFMnPqFjvDhFjgMZGUpr -Wl,-rpath,/Applications/ghc-7.10.2.app/Contents/lib/ghc-7.10.2/templ_1ejK907jvoTHoZ6iZtHeyN -Wl,-rpath,/Users/adam/Development/haskell/ghc-mod/.cabal-sandbox/7.10.2/lib/x86_64-osx-ghc-7.10.2/tempo_Il0r9HZboDhGin7P716nyP -Wl,-rpath,/Applications/ghc-7.10.2.app/Contents/lib/ghc-7.10.2/time_AXTdBF9VRQoBOqJT6qtmVH -Wl,-rpath,/Applications/ghc-7.10.2.app/Contents/lib/ghc-7.10.2/trans_3eG64VdP2vzGjP6wJiCp5X -Wl,-rpath,/Users/adam/Development/haskell/ghc-mod/.cabal-sandbox/7.10.2/lib/x86_64-osx-ghc-7.10.2/trans_DCQioW2d4vYEa3T0AmFBPv -Wl,-rpath,/Applications/ghc-7.10.2.app/Contents/lib/ghc-7.10.2/unix_A3WgcI5QiHK4PDo4jSYdwQ -Wl,-rpath,/Users/adam/Development/haskell/ghc-mod/.cabal-sandbox/7.10.2/lib/x86_64-osx-ghc-7.10.2/utf8s_829v6sytxoOCoVhDxsM0Nt -nostdlib -Wl,-r -o dist/dist-sandbox-69331a4b/build/cabal-helper-wrapper/cabal-helper-wrapper-tmp/CabalHelper/Data.p_o -Wl,-filelist -Wl,/var/folders/ly/6v5y6xws2_x0zj4k7vhhclsw0000gp/T/ghc14194_0/ghc_10.filelist
ld: -rpath can only be used when creating a dynamic final linked image

I poked around some but can't figure out what's happening at all.

I'm not sure if this is the right place to report this so let me know if there's someplace else!

Thanks!

Adam

	componentsMap lbi v distdir $ \c clbi bi ->
	let
	#if CH_MIN_VERSION_Cabal(2,0,0)
	outdir = componentBuildDir lbi clbi
	#else
	outdir = componentOutDir lbi c
	#endif

	createProgSymlink :: FilePath -> FilePath -> IO ()
	createProgSymlink bindir target
	\| [exe] <- splitPath target = do
	Just exe_path <- findExecutable exe
	createSymbolicLink exe_path (bindir </> takeFileName target)
	\| otherwise = do
	cwd <- getCurrentDirectory
	createSymbolicLink (cwd </> target) (bindir </> takeFileName target)

danielg / cabal-helper Goto Github PK

cabal-helper's People

Contributors

Stargazers

Watchers

Forkers

cabal-helper's Issues

Recommend Projects

Recommend Topics

Recommend Org