summaryrefslogtreecommitdiff
path: root/compiler/main/DriverMkDepend.hs
Commit message (Collapse)AuthorAgeFilesLines
...
* Don't import FastString in HsVersions.hIan Lynagh2008-03-291-0/+1
| | | | Modules that need it import it themselves instead.
* Fix Makefile generatin on WindowsIan Lynagh2008-01-161-4/+4
|
* Fix generating dependencies for different ways now we use FilePathIan Lynagh2008-01-151-1/+3
| | | | | | | We were making filenames like dist/build/GHC/Base.p_.o rather than dist/build/GHC/Base.p_o
* Use System.FilePathIan Lynagh2008-01-121-3/+4
|
* Move OPTIONS pragmas above commentsIan Lynagh2007-09-211-7/+7
| | | | Fixes building with -Werror (i.e. validate) and GHC < 6.6
* Fix CodingStyle#Warnings URLsIan Lynagh2007-09-041-1/+1
|
* Use OPTIONS rather than OPTIONS_GHC for pragmasIan Lynagh2007-09-031-2/+2
| | | | | | | Older GHCs can't parse OPTIONS_GHC. This also changes the URL referenced for the -w options from WorkingConventions#Warnings to CodingStyle#Warnings for the compiler modules.
* Add {-# OPTIONS_GHC -w #-} and some blurb to all compiler modulesIan Lynagh2007-09-011-0/+7
|
* Remove code that is dead, as we require __GLASGOW_HASKELL__ >= 504Ian Lynagh2007-04-061-3/+0
|
* Add comments about the -include-prelude flag for ghc -Msimonpj@microsoft.com2007-03-271-0/+4
|
* Add -ddump-mod-cycles to -M behavioursimonpj@microsoft.com2007-03-221-5/+69
| | | | | | | | | | | | | | This patch adds a flag -ddump-mod-cycles to the "ghc -M" dependency analyser. The effect of ghc -M -ddump-mod-cycles is to dump a list of cycles foud in the module graph. The display is trimmed so that only dependencies within the cycle are shown; and the list of modules in a cycle is itself sorted into dependency order, so that it is easy to track the chain of dependencies. Open question: should the flag be "-ddump-mod-cycles" or "-optdep-dump-mod-cycles"? For this reason I have not yet added to the documentation.
* Module header tidyup #2Simon Marlow2006-10-111-8/+8
| | | | Push this further along, and fix build problems in the first patch.
* Generalise Package SupportSimon Marlow2006-07-251-15/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch pushes through one fundamental change: a module is now identified by the pair of its package and module name, whereas previously it was identified by its module name alone. This means that now a program can contain multiple modules with the same name, as long as they belong to different packages. This is a language change - the Haskell report says nothing about packages, but it is now necessary to understand packages in order to understand GHC's module system. For example, a type T from module M in package P is different from a type T from module M in package Q. Previously this wasn't an issue because there could only be a single module M in the program. The "module restriction" on combining packages has therefore been lifted, and a program can contain multiple versions of the same package. Note that none of the proposed syntax changes have yet been implemented, but the architecture is geared towards supporting import declarations qualified by package name, and that is probably the next step. It is now necessary to specify the package name when compiling a package, using the -package-name flag (which has been un-deprecated). Fortunately Cabal still uses -package-name. Certain packages are "wired in". Currently the wired-in packages are: base, haskell98, template-haskell and rts, and are always referred to by these versionless names. Other packages are referred to with full package IDs (eg. "network-1.0"). This is because the compiler needs to refer to entities in the wired-in packages, and we didn't want to bake the version of these packages into the comiler. It's conceivable that someone might want to upgrade the base package independently of GHC. Internal changes: - There are two module-related types: ModuleName just a FastString, the name of a module Module a pair of a PackageId and ModuleName A mapping from ModuleName can be a UniqFM, but a mapping from Module must be a FiniteMap (we provide it as ModuleEnv). - The "HomeModules" type that was passed around the compiler is now gone, replaced in most cases by the current package name which is contained in DynFlags. We can tell whether a Module comes from the current package by comparing its package name against the current package. - While I was here, I changed PrintUnqual to be a little more useful: it now returns the ModuleName that the identifier should be qualified with according to the current scope, rather than its original module. Also, PrintUnqual tells whether to qualify module names with package names (currently unused). Docs to follow.
* Reorganisation of the source treeSimon Marlow2006-04-071-0/+342
Most of the other users of the fptools build system have migrated to Cabal, and with the move to darcs we can now flatten the source tree without losing history, so here goes. The main change is that the ghc/ subdir is gone, and most of what it contained is now at the top level. The build system now makes no pretense at being multi-project, it is just the GHC build system. No doubt this will break many things, and there will be a period of instability while we fix the dependencies. A straightforward build should work, but I haven't yet fixed binary/source distributions. Changes to the Building Guide will follow, too.
View Lorry Controller Status