`cabal-install` gets horribly confused about sublibrary dependencies if they share a `hs-source-dirs`

[kozross]

Describe the bug

I have a project with two sublibraries, one of which depends on the other. Omitting irrelevant fields, the layout is thus:

library foo
    ...
    hs-source-dirs: src

library bar
   ...
   build-depends: foo
   hs-source-dirs: src

Notably, we see that both foo and bar share the same hs-source-dirs. When I try to do cabal build, the dependency of bar on foo is not detected: instead, I get GHC warnings about files needed for compilation not being noted as dependencies.

This can be fixed by changing the hs-source-dirs to this:

library foo
    ...
    hs-source-dirs: foo

library bar
   ...
   build-depends: foo
   hs-source-dirs: bar

or even this:

library foo
    ...
    hs-source-dirs: src/foo

library bar
   ...
   build-depends: foo
   hs-source-dirs: src/bar

To Reproduce
Steps to reproduce the behavior:

Set up two sublibraries as above, then call

$ cabal build

Expected behavior

Dependencies should be detected properly, and no warnings from GHC should be showing up due to 'missing' files needed for compilation.

System information

• Arch Linux
• Cabal 3.14.1.1 (same as cabal-install version)
• GHC 9.8.2

Additional context

This behaviour is quite long-standing: I only discovered this was a problem by finding a response from years ago specifying that sharing hs-source-dirs like this would trigger this behaviour.

[ffaf1]

Sharing hs-source-dirs is a bad idea, the User’s Guide warns about it (although not specifically about your problem).

I would be prone to add a warning to cabal check.

(Barrage of UX questions) Does this answer your report? Do you think from a UX point-of-view we are better off allowing folder-sharing components? Why did you choose such a setup?

[kozross]

@ffaf1 I would agree that some kind of more indicative warning or error would help considerably here. If sharing of this kind is considered bad practice, I would rather Cabal explicitly spell this out to me, if not ban it outright, rather than the current situation, which produces surprising behaviour unexplained.

[ffaf1]

That seems quite reasonable @kozross.

Now to understand why we don't outright disallow it, maybe there are some legitimate use cases (I found #6150 related to this).

Once we are sure on what to do, changes should not be difficult.

[Bodigrim]

There are legitimate use cases for sharing hs-source-dirs between independent components. For example, if a package has any rewrite {-# RULES #-} it is advisable to run tests with optimisations both on and off:

test-suite properties-O1
    hs-source-dirs:   test
    ghc-options:      -Wall -O1

test-suite properties-O0
    hs-source-dirs:   test
    ghc-options:      -Wall -O0

A potential warning should alert only when components sharing hs-source-dirs additionally depend on each other.