Okay, so then I have so troubles regarding the compilation of my executable: First, what do you think is the simpler : (1) build only the library through cabal-install and then the executable with ghc (it isn't to be distributed with the lib), or (2) add both to my http://old.nabble.com/file/p27515830/HSFML.cabal .cabal file and build them in the same time with a 'cabal build' ? Because I've tried both methods, and have had issues with both : (1) after a 'cabal build', ghc doesn't know where to find my library -- whereas cabal-install displays 'Registering HSFL-1.5...' at the end of the build -- when I do 'ghc --make main.hs'. I'm not gonna do a 'cabal install' whenever I alter my code, am I? (2) well, then, when building, if I don't specify that my executable depends on my lib, I got: SFML/Direct/Graphics.hs:51:7: Could not find module `SFML.Direct.Types.Enums': It is a member of the hidden package `HSFML-1.5'. Perhaps you need to add `HSFML' to the build-depends in your .cabal file. it is a hidden module in the package `HSFML-1.5' Use -v to see a list of the files searched for. and if I do what I asks me to add (I add the line 'Build-Depends: HSFML' in the 'Executable' section of my .cabal file), I'm told when 'cabal build'ing: cabal: internal error: could not construct a valid install plan. The proposed (invalid) plan contained the following problems: The following packages are involved in a dependency cycle HSFML-1.5 Miguel Mitrofanov wrote:

With cabal-install, usually.

-- View this message in context: http://old.nabble.com/Using-Cabal-during-development-tp27515446p27515830.htm... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

On Tue, Feb 9, 2010 at 6:10 AM, Ketil Malde wrote:

Limestraël writes:

...

how do usually Haskell developpers build their softwares (and especially medium or big libraries) while they are still developping them ? With cabal-install, by doing one 'cabal configure' once and 'cabal build' each time they have altered their code ? With only Cabal, through some 'runhaskell Setup.hs build's ?

Generally, the first thing I do is hit C-c C-l in Emacs to load the current file into a haskell process. Then back to fix the type errors (click on the error to jump to the code), and iterate until it loads correctly.

It's really unfortunate that this approach doesn't work for .hsc files. When writing low level libraries I often have a couple of these which forces me out of my nice Emacs workflow into an Emacs + terminal + Cabal workflow. -- Johan

* On Tue, Feb 09 2010, Johan Tibell wrote:

On Tue, Feb 9, 2010 at 6:10 AM, Ketil Malde wrote:

Limestraël writes:

> how do usually Haskell developpers build their softwares (and > especially medium or big libraries) while they are still developping them ? > With cabal-install, by doing one 'cabal configure' once and 'cabal build' > each time they have altered their code ? > With only Cabal, through some 'runhaskell Setup.hs build's ?

Generally, the first thing I do is hit C-c C-l in Emacs to load the current file into a haskell process.  Then back to fix the type errors (click on the error to jump to the code), and iterate until it loads correctly.

It's really unfortunate that this approach doesn't work for .hsc files. When writing low level libraries I often have a couple of these which forces me out of my nice Emacs workflow into an Emacs + terminal + Cabal workflow.

This is solve-able. I bind compile-command to the c2hs invocation, and then have my C-c C-l keybinding run "compile" before "inferior-haskell-load-file". The only hangup is that having a -*- comment at the top of a c2hs file confuses ghc when c2hs generates the code. So I set the buffer-local variable via eproject (in the .eproject file in the project root) instead, and everything is happy. I would post the exact code, but it's on my work machine, and it's nearly impossible to get files out of my work environment without getting nasty emails about how I'm stealing the company's IP. (But hey, at least I get to use Haskell. I can't complain too loudly :) Ping me on #haskell or #emacs if you need help getting something like this working. Oh; one other thing. You don't need to leave emacs to run cabal commands; you can run ":!cabal build" from the ghci window, you can bind compile-command to "cabal build" and run M-x compile, or you can use eshell. I use all three approaches depending on my mood. But since I'm on Windows, I certainly never venture outside of my Emacs window. :) Regards, Jonathan Rockway -- Just "another Haskell hacker"

Okay, but have you ever felt the need to make in the same project a library and an executable which depends on this library (even just like me, for testing purpose)? How would you do it? Jason Dusek wrote:

My development environment is a Screen with Bash, Vim and GHCi running.

If I can just load the files in GHCi or compile them with GHC without specifying many options or extensions, then I just do it that way. As soon as I feel a need to write a Makefile or a little build script, I write a Cabal file instead and switch to using `cabal-install'.

When I say "many" options or extensions, I nearly mean "any". Most projects of mine get a Cabal file at the point where I feel the need for the first `LANGUAGE' pragma. (I usually omit `LANGUAGE' pragmas, delegating to Cabal for that. I'm not sure whether this is good or bad practice.)

-- Jason Dusek _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- View this message in context: http://old.nabble.com/Using-Cabal-during-development-tp27515446p27518960.htm... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

Then how does the 'Executable' section of your .cabal look like? That's what I can't get working.

Suitably elided. Executable test hs-source-dirs: src, tests other-modules: Text.Yaml.Yay, Text.Yaml.Yay.Syck main-is: Main.hs build-depends: base, HsSyck, syb if flag(test) build-depends: QuickCheck >= 2.1 && < 2.2, test-framework-quickcheck2 >= 0.2 && < 0.3, test-framework >= 0.2 && < 0.3 else buildable: False Library Hs-Source-Dirs: src Exposed-Modules: Text.Yaml.Yay, Text.Yaml.Yay.Syck Other-Modules: Text.Yaml.Yay.Internal.Utils, Text.Yaml.Yay.Syck.Encoder, Text.Yaml.Yay.Syck.Decoder Build-Depends: base, HsSyck, syb if flag(test) -- Faster builds ghc-options: -O0 else -- Optimized builds ghc-options: -O2 if flag(nolib) buildable: False

Then how does the 'Executable' section of your .cabal look like? That's what I can't get working.

Executable vty-ui-demo Hs-Source-Dirs: src Main-is: Demo.hs Build-Depends: mtl >= 1.1 && < 1.2 The Main-is refers to src/Demo.hs. This example is from: http://hackage.haskell.org/packages/archive/vty-ui/0.2/vty-ui.cabal The "package description" link on any Hackage package page will link to the release's cabal file, so you can see how other folks have written their Executable sections. Hope that helps, -- Jonathan Daugherty

Don't you simply need to do what the error message says, and add (*in the Executable section*, at the end of the file): build-depends: SFML ? Limestraël wrote:

I think I must be dumb or something. I did my SFML.cabal exactly the way the packager of vty-ui did vty-ui.cabal, and I still have got the error when building: hs_src/SFML/Direct/Graphics.hs:51:7: Could not find module `SFML.Direct.Types.Enums': It is a member of the hidden package `SFML-1.5'. Perhaps you need to add `SFML' to the build-depends in your .cabal file. it is a hidden module in the package `SFML-1.5' Use -v to see a list of the files searched for.

My cabal file is http://old.nabble.com/file/p27522604/SFML.cabal here . Il you get to know why it doesn't work, please tell me, because I'm lost... I have a hs_src directory, which contains an SFML directory (the lib) and a demo.hs file. (the simple main) It's the way vty-ui package is done.

Jonathan Daugherty-4 wrote:

...

...

Then how does the 'Executable' section of your .cabal look like? That's what I can't get working.

Executable vty-ui-demo Hs-Source-Dirs: src Main-is: Demo.hs Build-Depends: mtl >= 1.1 && < 1.2

The Main-is refers to src/Demo.hs. This example is from:

http://hackage.haskell.org/packages/archive/vty-ui/0.2/vty-ui.cabal

The "package description" link on any Hackage package page will link to the release's cabal file, so you can see how other folks have written their Executable sections.

Hope that helps,

-- Jonathan Daugherty _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Am Mittwoch 10 Februar 2010 18:16:42 schrieb Limestraël:

Neil Brown-7 wrote:

...

Don't you simply need to do what the error message says, and add (*in the Executable section*, at the end of the file):

Nope, just check my previous message (my issue (2)):

I think http://www.haskell.org/ghc/docs/latest/html/Cabal/authors.html might help, example 3, a package containing a library and executable programs Name: TestPackage Version: 0.0 Cabal-Version: >= 1.2 License: BSD3 Author: Angela Author Synopsis: Package with library and two programs Build-Type: Simple Library Build-Depends: HUnit Exposed-Modules: A, B, C Executable program1 Main-Is: Main.hs Hs-Source-Dirs: prog1 Other-Modules: A, B Executable program2 Main-Is: Main.hs Hs-Source-Dirs: prog2 Other-Modules: A, C, Utils For the executable, you have to specify the source dirs and the modules *from the library you are developing* it needs. A little inconvenient, admittedly.

Limestrael wrote:

...

(2) well, then, when building, if I don't specify that my executable depends on my lib, I got: SFML/Direct/Graphics.hs:51:7: Could not find module `SFML.Direct.Types.Enums': It is a member of the hidden package `HSFML-1.5'. Perhaps you need to add `HSFML' to the build-depends in your .cabal file. it is a hidden module in the package `HSFML-1.5' Use -v to see a list of the files searched for.

and if I do what it asks me to do (to add the line 'Build-Depends: HSFML' in the 'Executable' section of my .cabal file), I'm told when 'cabal build'ing: cabal: internal error: could not construct a valid install plan. The proposed (invalid) plan contained the following problems: The following packages are involved in a dependency cycle HSFML-1.5

Eventually, I think using cabal during development may be convenient. The only drawback is that you have to specify each dependency and -- above all -- every module each time you add one.

When writing bindings-posix, bindings-glib etc., which have lots of modules, I used a shell script to take all modules under ./src to .cabal. What it did was: 1) for each subdirectory, create a .hs file that reimport all modules under that subdirectory; 2) list all .hs (and, in my case, also .hsc) under ./src and insert then into .cabal. I've found that scripts of this kind have been very usefull. They require you to follow some rules (like, say, all modules with name mapping to directories are always a reimport of submodules).

Then, to compile you executable with ghc (because Cabal is definitely not convient when you have a lib and an executable in the same package): ghc --make --package-conf pkg.conf.d main.hs

Again, should you have better/simpler ways to achieve this, I would be glad to know them.

I usually find useful, at first, to build only the executable and leave the library. When modules get stable enough, I separate both. Other scripts have been also usefull: one to check uncommited changes in all packages I'm working in, other to sync all my local packages with their repos. You could have a single 'b' script you could run like: b l # build and install your library in local database b t # build and run your test package executable b m # update module list in .cabal file for all your packages etc. Best, Maurício

On Thu, Feb 11, 2010 at 4:28 AM, Limestraël wrote:

Eventually, I think using cabal during development may be convenient. The only drawback is that you have to specify each dependency and -- above all -- every module each time you add one. Nevertheless, I'm not convinced regarding the use of Makefiles with Cabal. I happen to think it's a bit outsize. A shell script is enough. By the way, I've found another way to develop simultaneously a (or many) library(ies) and an executable. It would be to use a local ghc package database.

In my project directory, I do: ghc-pky init pkg.conf.d

It create a directory pkg.conf.d which will contain my local database.

Then all the libs must be configured with: cabal configure --package-db pkg.conf.d (or 'runhaskell Setup.hs configure --package-db pkg.conf.d' if you don't use cabal-install) Then build normally ('cabal build') Then, the little trouble is that you have to register you newly-built manually with a: cabal register --inplace (Anyone knows how to tell cabal to register automatically to the local pkg database?)

Then, to compile you executable with ghc (because Cabal is definitely not convient when you have a lib and an executable in the same package): ghc --make --package-conf pkg.conf.d main.hs

This is great - now I can do proper benchmarks against my libraries without doing all-at-once compilation (which seems to change how inlining works), while at the same time not cluttering up my real package db. I have this wrapped up into a shell script, but that assumes I'm not doing my benchmarks on windows. Antoine