Allow using cabal program itself as the external setup method #2633
Conversation
|
Just a -Werror issue. |
|
|
|
Right, will have to do that. |
|
BTW, @tibbe and I did this together, so the design has my +1 already. Needs some testing though. |
|
I believe I fixed the -Werror issue (and closed to old pull request due to a restriction on not using git push -f on haskell/cabal). Will look into |
|
I've addressed the backwards compat issue with |
| @@ -222,12 +223,12 @@ setupWrapper verbosity options mpkg cmd flags extraArgs = do | |||
| -- | |||
| determineSetupMethod :: SetupScriptOptions -> BuildType -> SetupMethod | |||
| determineSetupMethod options buildType' | |||
| | forceExternalSetupMethod options = externalSetupMethod | |||
| | buildType' == Custom = externalSetupMethod | |||
There was a problem hiding this comment.
This needs a comment that explains the logic.
There was a problem hiding this comment.
Yes the logic is a bit subtle. Could put in a comment here based on my explanation here #1938 (comment)
In particular we need to say that forceExternalSetupMethod is really about using an external process, due to parallel build concerns, since that's not totally clear.
|
LGTM. |
This fixes issues when the version of Cabal that cabal-install was built against differs from the one registered in the local package DB. Normally we compile an external setup against the local Cabal library, which could lead to failures or inconsistent results compared to using the internal method. This fixes haskell#2438 and fixes haskell#1938.
|
Let's merge! |
Allow using cabal program itself as the external setup method
|
Yarr! |
as these are likely caused by Cabal bug haskell/cabal#2633
This fixes issues when the version of Cabal that cabal-install was built
against differs from the one registered in the local package DB. Normally
we compile an external setup against the local Cabal library, which could
lead to failures or inconsistent results compared to using the internal
method.