#10643: GHC cannot import submodules when run from subfolder -------------------------------------+------------------------------------- Reporter: FPtje | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: subfolder Operating System: Unknown/Multiple | import submodule cd Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by svenpanne): I think the point where we disagree is what you call the ''"-i problem"'': For me it's not a problem at all, it's as easy as it gets without being too clever and confusing, and it's standard behavior (compare with e.g. C/C++'s include path handling). And ''"ghc is arbitrarily restricted to run from the root of the source directory"'' is not correct, either: It is just the case (again standard behavior) that the default search path just contains "." (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/separate- compilation.html#search-path). Regarding finding wrong modules: Extend your example Yes/A.hs (containing module Yes.A) Yes/B.hs (containing module Yes.b) with Yes/Yes/B.hs (containing module Yes.Yes.B) With your proposal when your cwd is the top-level "Yes", "ghc A.hs" would pick up the file containing Yes.Yes.B, which is not what you want, although it's in the perfectly right location. Another problem is: No build system of any kind should blindly go upwards in the directory hierarchy because of symbolic links, only downwards. And finally: In any non-toy program, having a single -i option is your least problem, so you will have a .cabal file, anyway. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10643#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler