-
Notifications
You must be signed in to change notification settings - Fork 701
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
Have to install twice package with 'custom-setup' stanza #3436
Comments
For reference, here is the
|
It seems to be related to having grayjay@6607bb7 I also noticed that the dependency solver doesn't enforce the |
I found the problem. cabal always chooses a Cabal library version to use for a package's setup script that doesn't take
cabalLibVersion depends on the cabal-version field, the installed versions of Cabal, etc., and it is used when setup dependencies are not chosen by the dependency solver. When a package has a setup-depends , cabalLibVersion is later ignored in favor of the version chosen by the dependency solver. The configure step in my test case fails because cabal uses a stale snapshot of the installed package index when choosing cabalLibVersion , and it doesn't see that Cabal-1.24.0.0 has been installed.
I think the solution is to only choose
Here is a commit that seems to work: grayjay@9f6cbea?w=1. It probably isn't complete, though. |
@grayjay are you still planning to fix this? |
@ezyang I'm not sure if my commit is the right approach. This issue could require a bigger change, but I'm not very familiar with the code that chooses the Cabal version. |
Previously, cabal always chose a Cabal library version to use for a package's setup script that didn't take setup-depends into account (cabalLibVersion). cabalLibVersion depended on the cabal-version field, the installed versions of Cabal, etc., and it was used when setup dependencies are not chosen by the dependency solver. When a package had a setup-depends, cabalLibVersion was later ignored in favor of the version chosen by the dependency solver. However, calculating the variable caused an error when the only suitable Cabal version was installed during the same install command (issue haskell#3436). It was also used to filter the configure flags (issue haskell#3433). This commit sets cabalLibVersion to the version chosen by the dependency solver, when possible.
Previously, cabal always chose a Cabal library version to use for a package's setup script that didn't take setup-depends into account (cabalLibVersion). cabalLibVersion depended on the cabal-version field, the installed versions of Cabal, etc., and it was used when setup dependencies were not chosen by the dependency solver. When a package had a setup-depends, cabalLibVersion was later ignored in favor of the version chosen by the dependency solver. However, calculating the variable caused an error when the only suitable Cabal version was installed during the same install command (issue haskell#3436). cabalLibVersion was also used to filter the configure flags (issue haskell#3433). This commit sets cabalLibVersion to the version chosen by the dependency solver, when possible.
I cleaned up my commit and made a PR, #3723. It worked with GHC 7.10.3 and |
Fix was merged! |
This works for me too, thanks a lot! |
Previously, cabal always chose a Cabal library version to use for a package's setup script that didn't take setup-depends into account (cabalLibVersion). cabalLibVersion depended on the cabal-version field, the installed versions of Cabal, etc., and it was used when setup dependencies were not chosen by the dependency solver. When a package had a setup-depends, cabalLibVersion was later ignored in favor of the version chosen by the dependency solver. However, calculating the variable caused an error when the only suitable Cabal version was installed during the same install command (issue haskell#3436). cabalLibVersion was also used to filter the configure flags (issue haskell#3433). This commit sets cabalLibVersion to the version chosen by the dependency solver, when possible. (cherry picked from commit 77fb0b9)
(cherry picked from commit 9ec4028)
Previously, cabal always chose a Cabal library version to use for a package's setup script that didn't take setup-depends into account (cabalLibVersion). cabalLibVersion depended on the cabal-version field, the installed versions of Cabal, etc., and it was used when setup dependencies were not chosen by the dependency solver. When a package had a setup-depends, cabalLibVersion was later ignored in favor of the version chosen by the dependency solver. However, calculating the variable caused an error when the only suitable Cabal version was installed during the same install command (issue haskell#3436). cabalLibVersion was also used to filter the configure flags (issue haskell#3433). This commit sets cabalLibVersion to the version chosen by the dependency solver, when possible. (cherry picked from commit 77fb0b9)
(cherry picked from commit 9ec4028)
haskell#4909 changed the cabal-version of the package under test, so this commit adjusts the versions of the Cabal libraries in the test to be consistent with the cabal-version.
Removes command and cleanups cabal-testsuite. The tests for haskell#3199 haskell#4099 haskell#3436 are removed, but they seem to be sandbox specific issues.
Removes command and cleanups cabal-testsuite. The tests for haskell#3199 haskell#4099 haskell#3436 are removed, but they seem to be sandbox specific issues.
Removes command and cleanups cabal-testsuite. The tests for haskell#3199 haskell#4099 haskell#3436 are removed, but they seem to be sandbox specific issues. Removes Sandbox.Types, Sandbox.Index and Sandbox.Timestamp modules. The Sandbox and Sandbox.PackageEnvironment are still there as some configuration in v1-commands happens through them (~/.cabal/config vs ./cabal.config). BuildExFlags contained only sandbox specific parameter, so it's removed as well. Remove sandbox support from cabal-testsuite Remove sandbox from GlobalFlags and Sandbox unit-tests
I just uploaded a new version of the
gi-glib
package to hackage using the newcustom-setup
stanza, butcabal install
fails to install it on the first try:Notice that
Cabal-1.24.0.0
was installed properly, but somehow the configure ofgi-glib
still fails. But repeating the command now suceeds:The text was updated successfully, but these errors were encountered: