cabal doesn't explore the none manual flags very well
Hey all, i'm repeatedly seeing many examples where a Manual : False flag is used to encode an "OR" in the cabal configuration, and where cabal "gives up" on finding the "right" build plan i know it can find if it has to flip the flag in a dependency its building... Is this a known issue? how can i mitigate it?
Hi there.
i'm repeatedly seeing many examples where a Manual : False flag is used to encode an "OR" in the cabal configuration, and where cabal "gives up" on finding the "right" build plan i know it can find if it has to flip the flag in a dependency its building...
Is this a known issue? how can i mitigate it?
It wasn't really known to me until recently. I'm currently looking at this issue, but I unfortunately don't have much time to work on it. As a workaround, it might help to add a package for which a suboptimal version is chosen because the flag is set to the wrong value explicitly as a target on the command line. Cheers, Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com
Here's one example, and a comment for a possible long-term solution from Duncan Coutts: https://github.com/bos/aeson/issues/177 Best, Leon On Wed, Mar 12, 2014 at 1:55 PM, Andres Löh <andres@well-typed.com> wrote:
Hi there.
i'm repeatedly seeing many examples where a Manual : False flag is used to encode an "OR" in the cabal configuration, and where cabal "gives up" on finding the "right" build plan i know it can find if it has to flip the flag in a dependency its building...
Is this a known issue? how can i mitigate it?
It wasn't really known to me until recently.
I'm currently looking at this issue, but I unfortunately don't have much time to work on it. As a workaround, it might help to add a package for which a suboptimal version is chosen because the flag is set to the wrong value explicitly as a target on the command line.
Cheers, Andres
-- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Hi. On Wed, Mar 12, 2014 at 7:16 PM, Leon Smith <leon.p.smith@gmail.com> wrote:
Here's one example, and a comment for a possible long-term solution from Duncan Coutts:
Yes, thanks. This is in fact what prompted me looking at it. I think we can probably do a bit better by default even without adding a new kind of flags. But it'll require a (hopefully small) change to the solver, and as it's a heuristic, there's always a risk some other situations might get worse. Cheers, Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com
Hi there. I've pushed an experimental quick fix to https://github.com/kosmikus/cabal/tree/defer-flags I've briefly verified that it seems to fix the aeson issue mentioned in https://github.com/kosmikus/cabal/tree/defer-flags and one other test case I had lying around, but I haven't tested anything else. This change needs much more testing and experimentation. But if you'd like to try it, I'd welcome feedback on whether it at least solves a few concrete instances of this problem. Cheers, Andres On Wed, Mar 12, 2014 at 7:35 PM, Andres Löh <andres@well-typed.com> wrote:
Hi.
On Wed, Mar 12, 2014 at 7:16 PM, Leon Smith <leon.p.smith@gmail.com> wrote:
Here's one example, and a comment for a possible long-term solution from Duncan Coutts:
Yes, thanks. This is in fact what prompted me looking at it. I think we can probably do a bit better by default even without adding a new kind of flags. But it'll require a (hopefully small) change to the solver, and as it's a heuristic, there's always a risk some other situations might get worse.
Cheers, Andres
-- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com
-- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com
participants (3)
-
Andres Löh -
Carter Schonwald -
Leon Smith