Ignore source files that are used as main when inferring modules

[sol]

(fixes #188)

[sol]

This PR attempts to address #188. However, this is non-trivial. I'm not even sure if there is a sound solution. Consider the following:

# source files:
#
#   linux/L.hs
#   windows/W.hs
#   src/L.hs

executable:
  when:
    condition: os(windows)
    then:
      source-dirs:
        - windows
        - src
      main: W.hs
    else:
      source-dirs: linux
      main: L.hs

With this PR we will get the following output:

executable foo
  if os(windows)
    main-is: W.hs
    hs-source-dirs:
        windows
        src
  else
    main-is: L.hs
    hs-source-dirs:
        linux

specifically, other-modules: L is not mentioned under if os(windows), while arguably, a user would want to have it there.

Ignoring any code for now, can we conceptually come up with an algorithm that produces sensible results?

One of the issues is that main-is and hs-source-dirs "interact" with each other, but they can be specified in different places. From what I understand, Cabal will evaluate the conditionals, eliminate everything that is false and then interpret the whole thing as if it were specified sequentially, adding a kind of procedural component to the mix (akin to what @quasicomputational already described in #255).

For the example above, we know that the two branches of the if-statement are mutually exclusive, giving us additional information that we could work with. But conceptually you could have something like:

when:
  - condition: ...
    main: ...
  - condition: ...
    source-dirs: ...
  - condition: ...
    ...

Here I don't think it is statically decidable how things interact. (statically == independent of a specific build configuration)

[sol]

@mpilgrem @andreasabel do you have any opinion on this?

[mpilgrem]

My immediate reaction, which may be harsh, is that people often co-locate related modules but this 'problem' (#188) arises because somebody has co-located unrelated modules (modules that relate to one test suite executable have been co-located with ones that relate to a different test suite executable). Is that a 'problem' that Hpack wants to fix?

EDIT: The Stack project has modules for unit tests that are co-located. However, those modules are related, as follows. They all relate to a single test suite executable, as the Stack project uses the Hspec framework and:

-- Spec.hs
{-# OPTIONS_GHC -Wno-missing-export-lists #-}
{-# OPTIONS_GHC -F -pgmF hspec-discover   #-}

[andreasabel]

There has not been a lot of reaction on the original issue report from others (no "me too" chime-ins), so maybe the problem is not pressing.