Hi, I have been using ghc-mod for a long time and I can’t give it up now, but I have an annoying problem. When I have a cabal file with a library and an executable depending on the library (for example here https://github.com/bitonic/kant/blob/master/kant.cabal), ghc-mod is not happy, complaining in every file that Error:<command line>: cannot satisfy -package kant Where ‘kant’ is the package that the cabal file defines with the library that the executable needs. Note that if I issue ‘cabal configure; cabal build’, everything goes smoothly. Did anybody stumble on the same problem? Thanks, Francesco
Hi Francesco, To keep ghc-mod happy, you also have to keep ghci happy. What you probably need is a .ghci file in the directory with a ":set -isrc" line in it. You may also need to add other stuff to .ghci such as language extensions and whatever else is needed to load your project with ghci. Regards, CJ On 08/02/13 11:00, Francesco Mazzoli wrote:
Hi,
I have been using ghc-mod for a long time and I can’t give it up now, but I have an annoying problem.
When I have a cabal file with a library and an executable depending on the library (for example here https://github.com/bitonic/kant/blob/master/kant.cabal), ghc-mod is not happy, complaining in every file that
Error:<command line>: cannot satisfy -package kant
Where ‘kant’ is the package that the cabal file defines with the library that the executable needs. Note that if I issue ‘cabal configure; cabal build’, everything goes smoothly.
Did anybody stumble on the same problem?
Thanks, Francesco
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- CJ van den Berg mailto:cj@vdbonline.com xmpp:neurocyte@gmail.com
At Fri, 08 Feb 2013 11:11:06 +0100, CJ van den Berg wrote:
Hi Francesco,
To keep ghc-mod happy, you also have to keep ghci happy. What you probably need is a .ghci file in the directory with a ":set -isrc" line in it. You may also need to add other stuff to .ghci such as language extensions and whatever else is needed to load your project with ghci.
Hi CJ, Thanks for your answer. I had tried to do that (actually I had modified ‘ghc-ghc-options’, but the result should be the same), but it doesn’t fix the issue - and I don’t see why it should, since the problem here is about not satisfying a package dependency. Francesco
On 08/02/13 11:20, Francesco Mazzoli wrote:
At Fri, 08 Feb 2013 11:11:06 +0100, CJ van den Berg wrote:
To keep ghc-mod happy, you also have to keep ghci happy. What you probably need is a .ghci file in the directory with a ":set -isrc" line in it. You may also need to add other stuff to .ghci such as language extensions and whatever else is needed to load your project with ghci.
I had tried to do that (actually I had modified ‘ghc-ghc-options’, but the result should be the same), but it doesn’t fix the issue - and I don’t see why it should, since the problem here is about not satisfying a package dependency.
I downloaded your package and tried it. It does work. Kant.REPL, which it is trying to load, is in the kant package. So it is looking for either the installed kant package, or the source files for the kant package modules. How is that not a package dependency? Telling it where to find the source files will remove the need to find an installed kant package. -- CJ van den Berg mailto:cj@vdbonline.com xmpp:neurocyte@gmail.com
At Fri, 08 Feb 2013 11:39:19 +0100, CJ van den Berg wrote:
I downloaded your package and tried it. It does work.
So, what I have is bitonic@clay ~/src/kant (git)-[master] % cat .ghci :set -isrc And I still get the mentioned error. Did you take any other measures to make things work? I’m using ghc-mod version 1.11.3.
Kant.REPL, which it is trying to load, is in the kant package. So it is looking for either the installed kant package, or the source files for the kant package modules.
How is that not a package dependency? Telling it where to find the source files will remove the need to find an installed kant package.
OK, now I understand what you are doing: instead of making ghc-mod rely on cabal, you simply make it load the files directly. Which is a bit annoying in my case because I have some files that need to be preprocessed (alex/happy), but it would still be better than nothing. I can achieve the same result by simply moving the ‘cabal’ file, or by deleting the target. I guess that the ‘.ghci’ has (or should have) the same effect. Francesco
On 8 February 2013 22:25, Francesco Mazzoli
At Fri, 08 Feb 2013 11:39:19 +0100, CJ van den Berg wrote:
I downloaded your package and tried it. It does work.
So, what I have is
bitonic@clay ~/src/kant (git)-[master] % cat .ghci :set -isrc
Try also having ":set -isrc/dist" and possibly ":set -isrc/dist/<package name>" (not on a machine with Haskell so I can't test this); I think I've had to do something like that before.
And I still get the mentioned error. Did you take any other measures to make things work? I’m using ghc-mod version 1.11.3.
Kant.REPL, which it is trying to load, is in the kant package. So it is looking for either the installed kant package, or the source files for the kant package modules.
How is that not a package dependency? Telling it where to find the source files will remove the need to find an installed kant package.
OK, now I understand what you are doing: instead of making ghc-mod rely on cabal, you simply make it load the files directly. Which is a bit annoying in my case because I have some files that need to be preprocessed (alex/happy), but it would still be better than nothing. I can achieve the same result by simply moving the ‘cabal’ file, or by deleting the target. I guess that the ‘.ghci’ has (or should have) the same effect.
Francesco
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com
On 08/02/13 12:25, Francesco Mazzoli wrote:
At Fri, 08 Feb 2013 11:39:19 +0100, CJ van den Berg wrote:
I downloaded your package and tried it. It does work.
So, what I have is
bitonic@clay ~/src/kant (git)-[master] % cat .ghci :set -isrc
And I still get the mentioned error. Did you take any other measures to make things work? I’m using ghc-mod version 1.11.3.
Ah, I only just realised that you’re talking about the flymake error, not the inferior-mode error. The problem is pretty much the same though. flymake uses ghc --make, which can’t import the Kant module because it doesn’t know how to build Parser.y. ghc-ghc-options is the right place for flymake options to ghc.
Kant.REPL, which it is trying to load, is in the kant package. So it is looking for either the installed kant package, or the source files for the kant package modules.
How is that not a package dependency? Telling it where to find the source files will remove the need to find an installed kant package.
OK, now I understand what you are doing: instead of making ghc-mod rely on cabal, you simply make it load the files directly. Which is a bit annoying in my case because I have some files that need to be preprocessed (alex/happy), but it would still be better than nothing. I can achieve the same result by simply moving the ‘cabal’ file, or by deleting the target. I guess that the ‘.ghci’ has (or should have) the same effect.
Options in .ghci won’t fix flymake, only inferior-mode. ghc-ghc-options is the place to fix flymake, although it won’t help if the import fails anyway. Can’t you manually preprocess Parser.y so that ghc --make has a .hs file it can use? -- CJ van den Berg mailto:cj@vdbonline.com xmpp:neurocyte@gmail.com
At Fri, 08 Feb 2013 12:50:47 +0100, CJ van den Berg wrote:
On 08/02/13 12:25, Francesco Mazzoli wrote:
At Fri, 08 Feb 2013 11:39:19 +0100, CJ van den Berg wrote:
I downloaded your package and tried it. It does work.
So, what I have is
bitonic@clay ~/src/kant (git)-[master] % cat .ghci :set -isrc
And I still get the mentioned error. Did you take any other measures to make things work? I’m using ghc-mod version 1.11.3.
Ah, I only just realised that you’re talking about the flymake error, not the inferior-mode error. The problem is pretty much the same though. flymake uses ghc --make, which can’t import the Kant module because it doesn’t know how to build Parser.y.
No, that is not the problem, I have a manually preprocessed Parser.hs in place.
ghc-ghc-options is the right place for flymake options to ghc.
Tried setting ‘ghc-ghc-options’, still no luck. And by the way, running ‘ghc-mod’ manually doesn’t help either: bitonic@clay ~/src/kant (git)-[master] % cat .ghci :set -isrc bitonic@clay ~/src/kant (git)-[master] % ghc-mod check src/Kant/REPL.hs src/Kant/REPL.hs:0:0:Error:<command line>: cannot satisfy -package kant (use -v for more information)
Options in .ghci won’t fix flymake, only inferior-mode. ghc-ghc-options is the place to fix flymake, although it won’t help if the import fails anyway.
Can’t you manually preprocess Parser.y so that ghc --make has a .hs file it can use?
Well yes I can, but it’s a bit annoying. I think things would be easier if ‘ghc-mod’ just used cabal commands (e.g. ‘cabal build’) to check things. Francesco
Hi,
When I have a cabal file with a library and an executable depending on the library (for example here https://github.com/bitonic/kant/blob/master/kant.cabal), ghc-mod is not happy, complaining in every file that
Error:<command line>: cannot satisfy -package kant
Where ‘kant’ is the package that the cabal file defines with the library that the executable needs. Note that if I issue ‘cabal configure; cabal build’, everything goes smoothly.
I guess you don't install the "kant" library, right? If so, I will think how to treat this kind problem. --Kazu
At Fri, 08 Feb 2013 21:22:23 +0900 (JST), Kazu Yamamoto (山本和彦) wrote:
I guess you don't install the "kant" library, right?
If so, I will think how to treat this kind problem.
The ‘kant’ package is the package I’m developing and using ghc-mod on. It includes both a library and an executable. The executable target has ‘kant’ as a dependency. Francesco
The ‘kant’ package is the package I’m developing and using ghc-mod on.
Yes. I understand it.
It includes both a library and an executable. The executable target has ‘kant’ as a dependency.
What I asked is whether or not the "kant" library is installed by cabal. To edit a Haskell file for the "kant" executable, the current ghc-mod needs to find the "kant" library in global or user. I guess this bug does not exist in ghc-mod v1.11.1. --Kazu
At Fri, 08 Feb 2013 22:18:20 +0900 (JST), Kazu Yamamoto (山本和彦) wrote:
The ‘kant’ package is the package I’m developing and using ghc-mod on.
Yes. I understand it.
It includes both a library and an executable. The executable target has ‘kant’ as a dependency.
What I asked is whether or not the "kant" library is installed by cabal.
Well installing it has the big problem that each time I make a change to the interface I have to manually re-install, and this happens often since I’m in an early stage...
To edit a Haskell file for the "kant" executable, the current ghc-mod needs to find the "kant" library in global or user.
Right, but this is surely doable since cabal handles the situation fine. In general it seems that ghc-mod should work with cabal when it can.
I guess this bug does not exist in ghc-mod v1.11.1.
I’ll try with that. Francesco
Well installing it has the big problem that each time I make a change to the interface I have to manually re-install, and this happens often since I’m in an early stage...
I'm not saying that you should install it. But I just want to know your situation.
Right, but this is surely doable since cabal handles the situation fine. In general it seems that ghc-mod should work with cabal when it can.
Yes. This is a bug of the current ghc-mod. This behavior change was introduced by another guy, I guess. I need to look into his code. --Kazu
At Fri, 08 Feb 2013 22:39:07 +0900 (JST), Kazu Yamamoto (山本和彦) wrote:
Well installing it has the big problem that each time I make a change to the interface I have to manually re-install, and this happens often since I’m in an early stage...
I'm not saying that you should install it. But I just want to know your situation.
Oh OK, I took it as an advice. Yes, it works if I install it.
Right, but this is surely doable since cabal handles the situation fine. In general it seems that ghc-mod should work with cabal when it can.
Yes. This is a bug of the current ghc-mod. This behavior change was introduced by another guy, I guess. I need to look into his code.
Thanks a lot, I’ll downgrade and wait for a fix. Francesco
At Fri, 08 Feb 2013 13:43:12 +0000, Francesco Mazzoli wrote:
At Fri, 08 Feb 2013 22:39:07 +0900 (JST), Kazu Yamamoto (山本和彦) wrote:
Well installing it has the big problem that each time I make a change to the interface I have to manually re-install, and this happens often since I’m in an early stage...
I'm not saying that you should install it. But I just want to know your situation.
Oh OK, I took it as an advice. Yes, it works if I install it.
Right, but this is surely doable since cabal handles the situation fine. In general it seems that ghc-mod should work with cabal when it can.
Yes. This is a bug of the current ghc-mod. This behavior change was introduced by another guy, I guess. I need to look into his code.
Thanks a lot, I’ll downgrade and wait for a fix.
Francesco
I can confirm that 1.11.1 works. Francesco
Francesco,
I can confirm that 1.11.1 works.
I think I fixed this problem. Would you try the master branch? https://github.com/kazu-yamamoto/ghc-mod --Kazu
At Wed, 13 Feb 2013 15:32:57 +0900 (JST), Kazu Yamamoto (山本和彦) wrote:
Francesco,
I can confirm that 1.11.1 works.
I think I fixed this problem. Would you try the master branch?
Hi Kazu, Now I get another error: Error:<command line>: cannot satisfy -package wl-pprint even if ‘wl-pprint’ is installed, and ‘cabal configure; cabal build’ runs fine. Francesco
Now I get another error:
Error:<command line>: cannot satisfy -package wl-pprint
even if ‘wl-pprint’ is installed, and ‘cabal configure; cabal build’ runs fine.
It seems to me that you installed multiple GHCs and wl-pprint is not installed for one of them. Is my guess corrent? --Kazu
At Wed, 13 Feb 2013 19:51:15 +0900 (JST), Kazu Yamamoto (山本和彦) wrote:
Now I get another error:
Error:<command line>: cannot satisfy -package wl-pprint
even if ‘wl-pprint’ is installed, and ‘cabal configure; cabal build’ runs fine.
It seems to me that you installed multiple GHCs and wl-pprint is not installed for one of them. Is my guess corrent?
Nope :). I have one ‘ghc’, and this is my ‘ghc-pkg list’: http://hpaste.org/82293. ‘ghci -package wl-pprint’ runs just fine. Francesco
Nope :). I have one ‘ghc’, and this is my ‘ghc-pkg list’: http://hpaste.org/82293. ‘ghci -package wl-pprint’ runs just fine.
Uhhhm. Are you using sandbox? --Kazu
At Wed, 13 Feb 2013 22:01:35 +0900 (JST), Kazu Yamamoto (山本和彦) wrote:
Nope :). I have one ‘ghc’, and this is my ‘ghc-pkg list’: http://hpaste.org/82293. ‘ghci -package wl-pprint’ runs just fine.
Uhhhm. Are you using sandbox?
Actually it turns out that I have a ‘cabal-dev’ directory both in / and /src in the project folder, which is weird - could it be that ghc-mod invoked it? In any case, if I delete those, I get: bitonic@clay ~/src/kant (git)-[master] % ghc-mod check -g-v src/Kant/Syntax.hs Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.0 ... linking ... done. Loading package deepseq-1.3.0.0 ... linking ... done. Loading package containers-0.4.2.1 ... linking ... done. Loading package semigroups-0.8.4.1 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package comonad-3.0.0.2 ... linking ... done. Loading package contravariant-0.2.0.2 ... linking ... done. Loading package semigroupoids-3.0.0.1 ... linking ... done. Loading package bifunctors-3.0 ... linking ... done. Loading package prelude-extras-0.2 ... linking ... done. Loading package bound-0.5.0.2 ... linking ... done. Loading package prelude-extras-0.3 ... linking ... done. Loading package bound-0.6 ... linking ... done. Loading package bytestring-0.9.2.1 ... linking ... done. Loading package filepath-1.3.0.0 ... linking ... done. Loading package old-locale-1.0.0.4 ... linking ... done. Loading package old-time-1.1.0.0 ... linking ... done. Loading package unix-2.5.1.0 ... linking ... done. Loading package directory-1.1.0.2 ... linking ... done. Loading package terminfo-0.3.2.5 ... linking ... done. Loading package haskeline-0.7.0.3 ... linking ... done. Loading package mtl-2.1.1 ... linking ... done. Loading package text-0.11.2.0 ... linking ... done. Loading package parsec-3.1.2 ... linking ... done. Loading package transformers-0.2.2.0 ... linking ... done. Loading package mtl-2.0.1.0 ... linking ... done. Loading package parsec-3.1.3 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package wl-pprint-1.1 ... linking ... done. ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred ghc-mod:0:0:Probably mutual module import occurred Francesco
At Wed, 13 Feb 2013 13:24:48 +0000, Francesco Mazzoli wrote:
At Wed, 13 Feb 2013 22:01:35 +0900 (JST), Kazu Yamamoto (山本和彦) wrote:
Nope :). I have one ‘ghc’, and this is my ‘ghc-pkg list’: http://hpaste.org/82293. ‘ghci -package wl-pprint’ runs just fine.
Uhhhm. Are you using sandbox?
Actually it turns out that I have a ‘cabal-dev’ directory both in / and /src in the project folder, which is weird - could it be that ghc-mod invoked it?
In any case, if I delete those, I get:
[...]
Francesco
...but if I try it in Emacs it seems to work. So I guess that’s fine by me :). Thanks, Francesco
participants (4)
-
CJ van den Berg -
Francesco Mazzoli -
Ivan Lazar Miljenovic -
Kazu Yamamoto