Unix Dir for .hi Import Files

Alastair Reid reid@cs.utah.edu
10 Jun 2002 13:54:06 +0100

> At 2002-06-08 04:29, Alastair Reid wrote:
>> I don't see what's wrong with putting them in the same directory as
>> the .o file.  In fact, given that the .hi and .o file must match
>> exactly (i.e., be generasted from the same .hs file using the same
>> compiler version and same compiler flags), I see many things wrong
>> with putting them anywhere other than where the .o file is.

Ashley Yakeley <ashley@semantic.org> writes:
> So you don't think the .o files should be collected together into a
> library?

I hadn't meant to exclude this.

Let me restate my last sentence:

  It is essential to maintain a very clear connection between .o files
  and their corresponding .hi files.  The greater the distance between
  the files (in the directory tree), the greater the chance of
  mismatches occurring.

The problem could be reduced by improving GHC's ability to detect
mismatches.  For example, it'd be quite easy to include a 128-bit
fingerprint of the .hi file in the corresponding .o file _and_ in any
.hi and .o files whose contents may be affected by the .hi file and to
check that fingerprint at link time.  (I'm not completely sure of the
consequences for the fine-grained dependency analysis that GHC uses to
optimize make but I think it just makes it trickier not impossible.)

This would only solve part of the problem though.  The other part is
that having the files separate confuses the programmer and even a
linktime check is too late for people building big libraries or
really big programs (like GHC itself).