Build of colour package is broken by #5284
#5318
Comments
|
Reproduced it by setting up a sandbox for a package depending on |
|
I've got the bug: the default |
PR haskell#5284 changed things around, and now matchDirFileGlob will break if it's passed a null directory, which happens to be the default value for data-dir. Its call sites have been fixed to check for this and to substitute '.' for an empty path, which is the desired behaviour; in addition, matchDirFileGlob itself will now warn about this if it's detected, so that new broken call sites can't sneak in. Fixes haskell#5318.
PR haskell#5284 changed things around, and now matchDirFileGlob will break if it's passed a null directory, which happens to be the default value for data-dir. Its call sites have been fixed to check for this and to substitute '.' for an empty path, which is the desired behaviour; in addition, matchDirFileGlob itself will now warn about this if it's detected, so that new broken call sites can't sneak in. Fixes haskell#5318.
PR haskell#5284 changed things around, and now matchDirFileGlob will break if it's passed a null directory, which happens to be the default value for data-dir. Its call sites have been fixed to check for this and to substitute '.' for an empty path, which is the desired behaviour; in addition, matchDirFileGlob itself will now warn about this if it's detected, so that new broken call sites can't sneak in. Fixes haskell#5318.
PR haskell#5284 changed things around, and now matchDirFileGlob will break if it's passed a null directory, which happens to be the default value for data-dir. Its call sites have been fixed to check for this and to substitute '.' for an empty path, which is the desired behaviour; in addition, matchDirFileGlob itself will now warn about this if it's detected, so that new broken call sites can't sneak in. Fixes haskell#5318.
PR #5284 changed things around, and now matchDirFileGlob will break if it's passed a null directory, which happens to be the default value for data-dir. Its call sites have been fixed to check for this and to substitute '.' for an empty path, which is the desired behaviour; in addition, matchDirFileGlob itself will now warn about this if it's detected, so that new broken call sites can't sneak in. Fixes #5318.
|
I'm encountering a similar issue when running The build fails as: EDIT: with |
|
@TerrorJack You might also want to try with GHC HEAD against Cabal commit 218c7bf, if your bisection doesn't find an obvious GHC bug. That's the last Cabal commit before the globstar change; if that works but Cabal HEAD doesn't, it's probably something else that I managed to break... |
|
@quasicomputational Thanks for pointing that out! I built ghc-head with your specified commit and it worked. Cabal HEAD doesn't work though, even when I'm using |
|
GHC's Cabal submodule is cbdb135, but this bug's fix was merged in later (the very next commit, in fact). Just to be clear, since there are two sets of Cabal versions involved: you're seeing the failures with GHC HEAD plus cabal-install HEAD but with the Cabal submodule set to that commit, right? And you haven't touched the Cabal submodule? If that's the situation, then bumping GHC's Cabal submodule ought to make this go away. (I'm still building GHC from a dead start, so I can't test this myself yet, but I'll do that as soon as I'm able...) |
|
/cc @bgamari |
|
One more piece of the puzzle: |
|
The bug indeed vanishes with a bumped Cabal submodule. I'll open a GHC ticket about that, since there's not much to do from the Cabal side now. |
|
GHC ticket: http://ghc.haskell.org/trac/ghc/ticket/15254 |
This also significantly improves the error when trying to refer to missing directories, hopefully making it clear that it's coming from Cabal. haskell#5318 and snowleopard/hadrian#634 are two bugs which manifested as Cabal trying to glob in a non-existent directory and both took some debugging because of the obscurity of the error.
This also significantly improves the error when trying to refer to missing directories, hopefully making it clear that it's coming from Cabal. haskell#5318 and snowleopard/hadrian#634 are two bugs which manifested as Cabal trying to glob in a non-existent directory and both took some debugging because of the obscurity of the error.
This also significantly improves the error when trying to refer to missing directories, hopefully making it clear that it's coming from Cabal. haskell#5318 and snowleopard/hadrian#634 are two bugs which manifested as Cabal trying to glob in a non-existent directory and both took some debugging because of the obscurity of the error.
This also significantly improves the error when trying to refer to missing directories, hopefully making it clear that it's coming from Cabal. haskell#5318 and snowleopard/hadrian#634 are two bugs which manifested as Cabal trying to glob in a non-existent directory and both took some debugging because of the obscurity of the error.
This also significantly improves the error when trying to refer to missing directories, hopefully making it clear that it's coming from Cabal. haskell#5318 and snowleopard/hadrian#634 are two bugs which manifested as Cabal trying to glob in a non-existent directory and both took some debugging because of the obscurity of the error.
This also significantly improves the error when trying to refer to missing directories, hopefully making it clear that it's coming from Cabal. #5318 and snowleopard/hadrian#634 are two bugs which manifested as Cabal trying to glob in a non-existent directory and both took some debugging because of the obscurity of the error.
Running
cabal new-buildin a project that depends on thecolourpackage (assuming that the colour package is not already in the store) fails as follows:I ran git bisect and the problem was introduced in #5284 and is still present in current HEAD (765de7b).
The problem only occurs when
colouris registered into the store, if youcabal get colourand then try to build that package as an inplace package it works fine.I tried playing with verbose options but haven’t managed to get any useful info out of this so far.
The
colourpackage doesn’t seem to use any globs andcabal checkis happy, so this looks like a bug in cabal (rather than a bug in the cabal file of colour).cc @quasicomputational
The text was updated successfully, but these errors were encountered: