From: simonmar Date: Mon, 28 Feb 2000 10:14:27 +0000 (+0000) Subject: [project @ 2000-02-28 10:14:27 by simonmar] X-Git-Tag: Approximately_9120_patches~5091 X-Git-Url: http://git.megacz.com/?a=commitdiff_plain;h=33fd067bdf67eccb4085da36c9c793b029eed0ef;p=ghc-hetmet.git [project @ 2000-02-28 10:14:27 by simonmar] document the -recomp option explicitly. --- diff --git a/ghc/docs/users_guide/using.sgml b/ghc/docs/users_guide/using.sgml index 2a9dc56..c2fa0d0 100644 --- a/ghc/docs/users_guide/using.sgml +++ b/ghc/docs/users_guide/using.sgml @@ -925,24 +925,40 @@ Haskell libraries. The recompilation checker - recompilation checker + + + + + + option + + +Turn on recompilation checking. This will stop compilation early, +leaving an existing .o file in place, if it can +be determined that the module does not need to be recompiled. + + + + -In the olden days, GHC compared the newly-generated .hi file with -the previous version; if they were identical, it left the old one -alone and didn't change its modification date. In consequence, -importers of a module with an unchanged output .hi file were not -recompiled. +In the olden days, GHC compared the newly-generated +.hi file with the previous version; if they were +identical, it left the old one alone and didn't change its +modification date. In consequence, importers of a module with an +unchanged output .hi file were not recompiled. -This doesn't work any more. In our earlier example, module C does -not import module A directly, yet changes to A.hi should force a -recompilation of C. And some changes to A (changing the -definition of a function that appears in an inlining of a function -exported by B, say) may conceivably not change B.hi one jot. So +This doesn't work any more. In our earlier example, module +C does not import module A +directly, yet changes to A.hi should force a +recompilation of C. And some changes to +A (changing the definition of a function that +appears in an inlining of a function exported by B, +say) may conceivably not change B.hi one jot. So now… @@ -951,29 +967,37 @@ GHC keeps a version number on each interface file, and on each type signature within the interface file. It also keeps in every interface file a list of the version numbers of everything it used when it last compiled the file. If the source file's modification date is earlier -than the .o file's date (i.e. the source hasn't changed since the -file was last compiled), GHC will be clever. It compares the version -numbers on the things it needs this time with the version numbers on -the things it needed last time (gleaned from the interface file of the -module being compiled); if they are all the same it stops compiling -rather early in the process saying “Compilation IS NOT required”. -What a beautiful sight! - - - -GHC only keeps detailed dependency information for “user” modules, -not for “library” modules. It distinguishes the two by a hack: a module -whose .hi file has an absolute path name is considered a library module, -while a relative path name indicates a user module. So if you have a -multi-directory application, use relative path names in your - path, to force GHC to record detailed dependency information. -Use absolute path names only for directories containing slowly-changing +than the .o file's date (i.e. the source hasn't +changed since the file was last compiled), and the + is given on the command line, GHC will be +clever. It compares the version numbers on the things it needs this +time with the version numbers on the things it needed last time +(gleaned from the interface file of the module being compiled); if +they are all the same it stops compiling rather early in the process +saying “Compilation IS NOT required”. What a beautiful +sight! + + + +GHC only keeps detailed dependency information +for “user” modules, not for “library” modules. +It distinguishes the two by a hack: a module whose +.hi file has an absolute path name is considered +a library module, while a relative path name indicates a user module. +So if you have a multi-directory application, use +relative path names in your +path, to force GHC to record detailed dependency information. Use +absolute path names only for directories containing slowly-changing library modules. -A path is considered “absolute” if it starts with “/”, or -“A:/”, or “A:\” (or “B:/”, “B:\” etc). +A path is considered “absolute” if it starts with +“/”, or +“A:/”, or +“A:\” (or +“B:/”, +“B:\” etc).