A more flexible mechanism to define search paths
GHC mechanism for finding interface and object files imposes some constraints that make invocations harder than necessary when trying to separate the source code tree from the results of compilation. This ticket proposes some changes to make the search mechanism more flexible.
GHC offers the -i
flag to search interface and object files next to the source code. If the artifacts of compilation are kept elsewhere, the only alternative is to use the flags -odir
and -hidir
. There are a few problems with the current meaning of these flags.
-
-odir
and-hidir
not only specify where to look for object and interface files, they are also used to specify where the compiler should place newly generated artifacts. This is inconvenient if the outputs of different invocations need to be kept separated. -
-odir
and-hidir
can be specified only once. If there are input object and interface files spread in different locations, they need to be copied to a common location first.
Proposal
We would need to implement new flags:
--input-hidir DIR: appends DIR to the search path of interface files, can be specified multiple times
--input-odir DIR: appends DIR to the search path of object files, can be specified multiple times
There would be a search path for interface files, and another search path for object files. These search paths are used to look for the interface and object files not coming from an installed package. A search path is a sequence of directories, and files are looked on each directory in the order in which they appear in the sequence.
The search paths are initially empty, then they are appended with the directories specified with --input-hidir
and --input-odir
, and finally they are appended with the directories specified with -i
, -odir
, and -hidir
.
This is related to #20569 (closed).