CODEWITHSUNDEEP
haskellghcihaskell-platform
simon
simon

Reputation: 291

Haskell / GHCi - loading modules from different directories

My haskell application has the following directory structure:

src/
    utils/Utils.hs
    subsystem/Subsystem.hs

The Subsystem module imports Utils module. I would like to hand test this code in GHCi.

The problem is GHCi seems to be only looking for modules available in '.' (current directory), so I copied Utils.hs to subsystem folder and was able to hand-test Subsytem.hs. Is there a better way to do this? For example I would like to start GHCi in the src directory and let it search for modules in ./utils and ./subsystem directories. Can I specify a module path to GHCi?

Upvotes: 29

Views: 10291

Answers (4)

cevaris
cevaris

Reputation: 5794

If you project looks like the following...

src/
    utils/Utils.hs
    subsystem/Subsystem.hs
.....
myproject.cabal
Setup.hs

You can create a .ghci file in the root directory of the project, same directory that src, myproject.cabal and Setup.hs is in. The content of .gchi should be this..

:set -isrc/utils -isrc/subsystem

Now you can call ghci from the root directory of your project and it will auto-load any linked modules.

$ ghci
GHCi, version 7.8.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude>:load src/subsystem/Subsystem.hs
... should load Subsystem.hs

Upvotes: 5

hammar
hammar

Reputation: 139910

You can tell GHCi where to search for modules by using the -i option:

ghci Foo.Bar -isrc

This will load src/Foo/Bar.hs into GHCi. This way, you can also specify two different directories like this:

ghci Bar.hs -i.:config

It will look for the dependencies in ./ and ./config/ .

See the GHC user's guide for more information about the module search path.

Upvotes: 23

mightybyte
mightybyte

Reputation: 7282

You can create a .ghci file with something like this:

:set -isrc -iutils -isubsystem

Upvotes: 10

C. A. McCann
C. A. McCann

Reputation: 77404

By default, when GHC looks for modules, it interprets Foo.Bar as Foo/Bar.hs. So if you have a single project, you could have a module Utils as Utils.hs in the top-level directory, and a module Utils.Fishcakes as Utils/Fishcakes.hs. Note that Utils.hs can exist alongside a directory named Utils, or both can exist independently. A common style tends to be using the top-level module to simply re-export things from modules below it in the hierarchy, but this isn't required. The GHC User Guide covers the above behavior, as well as describing what other options are supported.

As far as I know, in most cases code will either use the above default structure, will use some other structure specified as part of a cabal build, or will expect to be installed as a library.

Upvotes: 11

Related Questions