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
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). -- Alastair