[[project @ 2005-06-21 12:03:25 by simonmar]
simonmar**20050621120325
Document changes to the package system.
A nice side effect of the relaxed restrictions is that the
-ignore-package flag is no longer required when compiling a package
(unless the package is "base", and even in that case we might be able
to get away with -hide-package base). For now, I've removed
references that talk about using -ignore-package when compiling a
package, and simplified the documentation for -ignore-package.
] {
hunk ./ghc/docs/users_guide/packages.xml 72
- the same module: in this case, only one of the packages can be
- exposed. This might happen if you have two versions of the same package
- installed, for example. The general rule is:
-
-
There must be no overlaps in the modules provided by all
- of the exposed packages, and the packages they depend on, and so
- on.
+ the same module: in this case, only one of the packages should be
+ exposed. It is an error to import a module that belongs to more than one
+ exposed package.
hunk ./ghc/docs/users_guide/packages.xml 168
- P is not installed at all. This is not
- the same as , because under
- the package might still be present
- in the program if another package depends on it.
-
- P
- not only causes package P to be removed,
- but also everything that depends on P,
- and so on.
+ P, and any packages that depend on
+ P, are not installed at all.
hunk ./ghc/docs/users_guide/packages.xml 171
- Why do we need ? Well, it is
- particularly useful when you're actually compiling package
- P itself. The compiler will refuse to
- compile module M if
- M is already part of a package. So we
- might try
- P; but then if
- P is a dependency of another package
- P' we would have to
- P' too;
- and the author of the code can't know in advance which packages are
- installed on the system and hence which
- flags are required. So, we provide
- which does the Right Thing.
+ Saying -ignore-package P is the same as
+ giving -hide-package flags for
+ P and all the packages that depend on
+ P. Sometimes we don't know ahead of time which
+ packages will be installed that depend on P,
+ which is when the -ignore-package flag can be
+ useful.
hunk ./ghc/docs/users_guide/packages.xml 183
+
+ The module overlap restriction
+
+ The module names in a Haskell program must be distinct.
+ This doesn't sound like a severe restriction, but in a Haskell program
+ using multiple packages with interdependencies, difficulties can start to
+ arise. You should be aware of what the module overlap
+ restriction means, and how to avoid it.
+
+ GHC knows which packages are in use by your
+ program: a package is in use if you imported something from it, or if it
+ is a dependency of some other package in use. There must be no conflicts
+ between the packages in use; a conflict is when two packages contain
+ a module with the same name. If
+ GHC detects a conflict, it will issue a message stating which packages
+ are in conflict, and which modules are overlapping.
+
+ For example, a conflict might arise if you use two packages, say P
+ and Q, which respectively depend on two different versions of another
+ package, say R-1.0 and R-2.0. The
+ two versions of R are likely to contain at least some
+ of the same modules, so this situation would be a conflict.
+
+
hunk ./ghc/docs/users_guide/packages.xml 344
-
-
- When compiling a Haskell module which is to be part of a new package
- P, use
- P.
-
}