Re: [Haskell-beginners] Cabal dependencies are per target or global?
I guess my example was incomplete. I can make GHC run. Here's a modified version where I do have the ghc-options line. I can build an executable for the second target (myPersonalMain) by commenting the "build-depends: section" for the first target (agent). My .cabal file with (commented lines) is: ------------------------------------------------ name: agent version: 0.1.0.0 build-type: Simple cabal-version: >=1.20 ------------------------------------------------ executable agent main-is: Main.hs hs-source-dirs: ./src -- build-depends: base >=4.6 && <4.7 -- , unordered-containers >= 0.2.3.0 -- , unix >= 2.6.0.1 -- , process >= 1.1.0.2 -- , stm >= 2.4.2 -- Base language which the package is written in. default-language: Haskell2010 ---------------------------------------------- executable myPersonalMain main-is: Mpm.hs hs-source-dirs: ./src ghc-options: -main-is Mpm build-depends: base >=4.4 default-language: Haskell2010 ---------------------------------------------- The contents of Mpm.hs are: module Mpm where main = putStrLn "Hi!" But if I remove the comments in the .cabal file above, I get this: Dis-machine:cabal-tests dimitri$ cabal build myPersonalMain ./agent.cabal has been changed. Re-configuring with most recently used options. If this fails, please run configure manually. Resolving dependencies... Configuring agent-0.1.0.0... cabal: At least the following dependencies are missing: process >=1.1.0.2, stm >=2.4.2, unix >=2.6.0.1, unordered-containers >=0.2.3.0 Is this a bug? Or am I missing something? Cheers, Dimitri On 17/07/15 15:10, Imants Cekusins wrote:
this could shed some light:
http://stackoverflow.com/questions/14238729/producing-multiple-executables-f...
answer #2 was marked as answered
ghc-options: -O2 -threaded -with-rtsopts=-N -main-is FirstExecutable
On Fri, Jul 17, 2015, at 04:08 PM, Dimitri DeFigueiredo wrote:
Is this a bug? Or am I missing something?
The dependencies are not global. You can see this by trying to import a module in Mpm.hs that is in one of the unique dependencies of "agent" - the import fails. [1] However, in order to build, you must first configure. And the "configure" step cannot be done for a single executable - it's done for the whole package. Since package dependencies are checked during the configure step, you have to have all the dependencies in place for all targets. I think this is probably a good thing, because otherwise, you could end up installing some packages that satisfy the dependencies of one target, only to find out that the particular package versions which were chosen make it impossible to satisfy the dependencies of the other target. -Karl 1. https://gist.github.com/ktvoelker/d561889ac4bd56cadc2d
Thanks Karl! The way cabal is working makes sense now. I don't like it, though. Having a build fail because of changes made to another target is counter-intuitive to me. I don't understand your argument for why the current behavior is a good thing. It seems we would be extending so called "cabal hell" to within targets in a package if we were to change this? I do wish there were other options here. Anyway, thanks again for the explanation! Dimitri Em 17/07/15 19:29, Karl Voelker escreveu:
Is this a bug? Or am I missing something? The dependencies are not global. You can see this by trying to import a module in Mpm.hs that is in one of the unique dependencies of "agent" -
On Fri, Jul 17, 2015, at 04:08 PM, Dimitri DeFigueiredo wrote: the import fails. [1]
However, in order to build, you must first configure. And the "configure" step cannot be done for a single executable - it's done for the whole package. Since package dependencies are checked during the configure step, you have to have all the dependencies in place for all targets.
I think this is probably a good thing, because otherwise, you could end up installing some packages that satisfy the dependencies of one target, only to find out that the particular package versions which were chosen make it impossible to satisfy the dependencies of the other target.
-Karl
1. https://gist.github.com/ktvoelker/d561889ac4bd56cadc2d _______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Hello Dimitri, I recommend you to use stack (https://github.com/commercialhaskell/stack) instead of cabal. Never had any problem with building since I started using it. It's awesome. It solved all my headaches caused by Cabal. But it still treats dependencies in the same way. Rene On Sat, Jul 18, 2015 at 6:47 PM, Dimitri DeFigueiredo < defigueiredo@ucdavis.edu> wrote:
Thanks Karl!
The way cabal is working makes sense now.
I don't like it, though. Having a build fail because of changes made to another target is counter-intuitive to me. I don't understand your argument for why the current behavior is a good thing. It seems we would be extending so called "cabal hell" to within targets in a package if we were to change this? I do wish there were other options here.
Anyway, thanks again for the explanation!
Dimitri
Em 17/07/15 19:29, Karl Voelker escreveu:
On Fri, Jul 17, 2015, at 04:08 PM, Dimitri DeFigueiredo wrote:
Is this a bug? Or am I missing something?
The dependencies are not global. You can see this by trying to import a module in Mpm.hs that is in one of the unique dependencies of "agent" - the import fails. [1]
However, in order to build, you must first configure. And the "configure" step cannot be done for a single executable - it's done for the whole package. Since package dependencies are checked during the configure step, you have to have all the dependencies in place for all targets.
I think this is probably a good thing, because otherwise, you could end up installing some packages that satisfy the dependencies of one target, only to find out that the particular package versions which were chosen make it impossible to satisfy the dependencies of the other target.
-Karl
1. https://gist.github.com/ktvoelker/d561889ac4bd56cadc2d _______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
_______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
On Sat, Jul 18, 2015, at 09:47 AM, Dimitri DeFigueiredo wrote:
I don't like it, though. Having a build fail because of changes made to another target is counter-intuitive to me. I don't understand your argument for why the current behavior is a good thing. It seems we would be extending so called "cabal hell" to within targets in a package if we were to change this? I do wish there were other options here.
Yes, that's exactly right - it would be another way to end up in cabal hell. There is another option, though: you could put the executables in separate packages. -Karl
participants (3)
-
Dimitri DeFigueiredo -
Karl Voelker -
René Klačan