> > This is intentional, and is part of a cleaning up of GHC's filename > > handling policies that we did recently. > > It may be conceptually cleaner, but in practice it seems to > make things > worse rather than better. I'm sure I can't be the only person to > store more than one Main module source file in a single directory? > With the current scheme, I'm seeing more errors than previously, > not fewer. > > > Previously, the .o file followed the filename, but the .hi > file followed > > the module name. Under this scheme, you would also run into trouble > > with having several Main modules in the same directory, > > Wouldn't the simpler solution be to follow hbc and nhc98's practice > of naming both the .hi and the .o file for the original filename, > rather than for Main? This seems to work well.
Darn. I really thought we'd got this filename stuff cleared up this time! It seems that every time we try to fix things someone comes up with a case that isn't handled the way they expect. Anyway, I've put the relevant section of the User's Guide here: http://www.haskell.org/~simonmar/separate-compilation.html Please take a look at section 4.6.2. It ought to be possible to incorporate your suggestion, but I have a nagging feeling that I'm forgetting something. > > Of course, you can always circumvent the default behaviour > by passing > > the appropriate command-line flags. > > I can see what flags to pass to plain one-pass ghc to fix this, but > what are the appropriate command-line flags to the --make variant to > ensure that the names of the .hi and .o files follow the filename and > not the module name? (The best option I could find was -no-recomp, > which despite its name appears to /force/ recompilation, but that > rather defeats the object of using ghc --make, doesn't it?) > > At the moment, the only good solution seems to be to abandon ghc > --make and revert to hmake to issue a series of one-shot ghc commands, > because at least it doesn't miss dependencies, even if it sometimes > comes up with too many. What missed dependencies are you referring to here? > (On a slight tangent related to the latter point, it often appears > that ghc updates the timestamp of a .hi file even if nothing in the > interface has actually changed. Is there a good reason for this? > The manual section 4.9.5 isn't very clear on the subject.) I think this is because we don't want 'make' to stop recompiling dependencies just because the current module didn't need any recompilation. It might be the case that modules further up the dependency tree still need recompiling. This is a result of the fact that .hi files don't contain the transitive closure of stuff they refer to any more (this change was made for Haskell 1.3, in GHC 2.1). Cheers, Simon _______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
