Defining CH executables in cabal files

[Duncan Coutts]

On Thu, 2013-04-04 at 15:46 +0100, Rob Stewart wrote:
> Hi Duncan, Edsko.
> 
> I'd like to know where I should most appropriately submit a bug
> report, or indeed whether the behaviour that I am experiencing is a
> bug or a user misuse of cabal.

It's a consequence of a misunderstanding of how package names affect
types and how different cabal constructs give you different package
names.

> I have packaged up a very simple send/receive example into a cabalised
> archive. In there is a README that describes the problem succinctly,
> though I will repeat here for convenience. It appears to be weirdness
> with main-is and hs-source-dirs. In the .cabal file, there are three
> executables of the same Receiver.hs file - a receiver of a CH message.
> One appears to be defined in such a way that the CH primitives `match`
> and `expect` are *not* receiving the message types that are being sent
> by Sender.hs.

The problem is that your three programs are using different types.

ch-receiver-1 and ch-receiver-2 use the type

        cabal-with-ch-executables-1.0:Bar.Baz.Types.Msg

while ch-receiver-3 uses the type

        Bar.Baz.Types.Msg

Those are the fully-qualified names of those types and they are
different, so they are different types, so have different Typeable
fingerprints and so the `expect` does not match them.

So as you can see, the fully qualified name of a type includes its
package id, and in the first case it has the package name
cabal-with-ch-executables-1.0 while in the second case it is the "home"
package, which has no name (or if you like, it's called "").

Code in a library has fully qualified names that include the package
name. Code in a top level executable is in the "home" package.

The way you've constructed your three programs, the first two put the
module in a library and the third puts it in the top level executable,
so according to ghc it really is a different module.

So lets look at your cabal file:

> library
>   default-language: Haskell2010
>   exposed-modules: Bar.Baz.Types
>                  , Bar.Baz.Identify
>   build-depends: base >= 4 && < 5
>                , binary >= 0.6.3.0
>                , bytestring >= 0.9.2
>                , distributed-process >= 0.4.2
>                , network
>                , network-transport
>                , network-transport-tcp
>   hs-source-dirs: src
>   GHC-Options: -Wall
>
> -- Works
> Executable ch-receiver-1
>   default-language: Haskell2010
>   main-is:        Receiver.hs
>   build-depends: base
>                , distributed-process
>                , network-transport-tcp
>                , network-transport
>                , cabal-with-ch-executables
>   hs-source-dirs: examples
>   ghc-options: -Wall
> 
> -- Works
> Executable ch-receiver-2
>   default-language: Haskell2010
>   main-is:        Receiver.hs
>   build-depends: base
>                , distributed-process
>                , network-transport-tcp
>                , network-transport
>                , cabal-with-ch-executables
>   hs-source-dirs: src/Bar/Baz
>   ghc-options: -Wall
> 
> -- Doesn't work
> Executable ch-receiver-3
>   default-language: Haskell2010
>   main-is:       Bar/Baz/Receiver.hs
>   build-depends: base
>                , distributed-process
>                , network-transport-tcp
>                , network-transport
>                , cabal-with-ch-executables
> 
>                -- I don't understand why these below are now needed??
>                , binary >= 0.6.3.0
>                , bytestring >= 0.9.2
>                , distributed-process >= 0.4.2
>                , network
>                , network-transport
>                , network-transport-tcp
>   hs-source-dirs: src
>   ghc-options: -Wall

So you have the first two executables depending on the library and they
pick up their Bar.Baz.Types module from the library.

Your third executable also depends on the library but the way you have
the sources organised means that you're getting the modules from the
source files and not from the library. This is because you're using the
hs-source-dirs as src, which is where the modules for the library live.
ghc will always pick local source files over modules from packages. This
is also why you needed those extra dependencies, your executable is
including those modules directly (you'll notice they're recompiled for
the 3rd exe).

The solution is that when you want to have an exe in a package depend on
a lib in the same package, you need to separate the src dirs, as you did
with the first one (hs-source-dirs: examples).

Clear as mud?

What would be good is if cabal would warn when the same module can be
found both in a local lib that we depend on, and as a source file,
because that's probably a mistake. It might also be good if we could
tell ghc where to get the modules from explicitly, rather than rely on
its behaviour about preferring src modules to package modules.

Duncan