new-build failure with custom-setup when setup-depends don't contain Cabal #4288
Milestone
Comments
|
does any one remember was there a bug in 1.24? The GHC-7.10.3 seems successfully register stuff: But otoh, |
I see there is comment in but why there is both ping @dcoutts EDIT this is Cabal with diff --git a/cabal-install/Distribution/Client/ProjectBuilding.hs b/cabal-install/Distribution/Client/ProjectBuilding.hs
index 8733dbe..2aa1f69 100644
--- a/cabal-install/Distribution/Client/ProjectBuilding.hs
+++ b/cabal-install/Distribution/Client/ProjectBuilding.hs
@@ -1086,6 +1086,8 @@ buildInplaceUnpackedPackage verbosity
mipkg <- if elabRequiresRegistration pkg
then do
ipkg0 <- generateInstalledPackageInfo
+ print "register"
+ print ipkg0
not sure where from the first register is even called. |
|
hmm.. Interestingly, if i EDIT verifying currently with travis build. |
|
Just bumped into this as well. |
|
I wonder why the setup script compiled without |
phadej
changed the title
|
@23Skidoo edited the original issue with minimal example. if |
|
@phadej Thanks, that clears it. |
|
At a guess, this is probably because cabal-install is applying an upper bound to the choice of Cabal library, even when an older version of Cabal wouldn't work with a new GHC? Though I'm a bit confused because 1.24 should be a permitted version in any case. |
31 tasks
|
Recently encountered something similar in stack - commercialhaskell/stack#3560 (comment) . Should there always be an implicit dependency on Cabal for Setup.hs? I don't think there should be. What if there is a modified version of Cabal that has a different name? Now the implicit dep on Cabal could cause module ambiguity. |
|
@mgsloan I wasn't able to reproduce this issue, but I don't think cabal-install should add an implicit dependency on Cabal in this case. I think there are only two places where it adds implicit dependencies:
|
|
I made a mistake before, and I can actually reproduce this bug with cabal/cabal-install/Distribution/Client/ProjectPlanning.hs Lines 2894 to 2897 in 7eb9903 With an explicit Cabal dependency, cabal chose that dependency's version (1.24.0.0) at line 2896. Without the direct dependency, cabal chose the package's cabal spec version at line 2897, which was 1.10. I think that |
grayjay
added a commit
to grayjay/cabal
that referenced
this issue
Feb 26, 2018
…c version. Fixes haskell#4288. Previously, new-build only looked for a direct dependency on Cabal when choosing the spec version to use for running the setup script. When the setup script only had a transitive dependency on Cabal, cabal used the package's cabal-version field, which could easily differ from the actual Cabal dependency's version. Then cabal could pass flags to the setup script that weren't recognized by the Cabal dependency. This commit considers any setup dependency on Cabal when choosing the Cabal spec version.
grayjay
added a commit
to grayjay/cabal
that referenced
this issue
Feb 26, 2018
4 tasks
grayjay
added a commit
to grayjay/cabal
that referenced
this issue
Mar 8, 2018
…c version. Fixes haskell#4288. Previously, new-build only looked for a direct dependency on Cabal when choosing the spec version to use for running the setup script. When the setup script only had a transitive dependency on Cabal, cabal used the package's cabal-version field, which could easily differ from the actual Cabal dependency's version. Then cabal could pass flags to the setup script that weren't recognized by the Cabal dependency. This commit considers any setup dependency on Cabal when choosing the Cabal spec version. (cherry picked from commit ea01b9d)
grayjay
added a commit
to grayjay/cabal
that referenced
this issue
Mar 8, 2018
(cherry picked from commit f4f382a)
4 tasks
Sonna
added a commit
to Sonna/toy-robot-haskell
that referenced
this issue
Mar 29, 2018
Fix the setup of this Haskell project within CircleCI and when setting up on a new machine or within Docker. This required that `Haq` not be considered a Library (without an executable), but instead an exposed module that was built and included within both the base project, as well as its tests. This should resolve problems that where occurring when running `cabal install` == Notes: - Change the order of `cabal update` with `cabal sandbox init`, since update will only run it there is a sandbox available, which is not present in the Haskell image container - Add `--enable-tests` and `--enable-documentation` to cabal install to slience other warnings == References: - [How to write a Haskell program \- HaskellWiki] (https://wiki.haskell.org/How_to_write_a_Haskell_program#Add_some_tests) - [cabal \- Set up Haskell Project and run tests \- Stack Overflow] (https://stackoverflow.com/questions/38928802/set-up-haskell-project-and-run-tests) - [Cabal\-Install \- HaskellWiki] (https://wiki.haskell.org/Cabal-Install) - [Invoking Haddock — Haddock 1\.0 documentation] (http://haskell-haddock.readthedocs.io/en/latest/invoking.html) - [new\-build failure with custom\-setup when setup\-depends don't contain Cabal · Issue \#4288 · haskell/cabal] (haskell/cabal#4288) - [2\.1\. Configuration — Cabal <release> User's Guide] (https://www.haskell.org/cabal/users-guide/installing-packages.html)
ysangkok
referenced
this issue
in commercialhaskell/stackage
Mar 21, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
custom-issue.cabal:Setup.hs:Steps to reproduce
Output
Workaround
Cabaltosetup-dependsOriginal issue
Reproducible with ghc-8.0.1 and ghc-8.0.2
Steps to reproduce
/note/
-j1isn't necessaryAdditional info
part of new-build log building the distributive
That directory doesn't seem to exist.
The text was updated successfully, but these errors were encountered: