On Mon, Jun 13, 2005 at 04:06:39PM +0100, Simon Marlow wrote:
On 13 June 2005 14:34, Serge D. Mechveliani wrote:
I am testing packages in ghc-6.4. I set docon.cabal,
which declares dependence on `data': build-depends: data The attempt to build docon by
cd $doconSource runhaskell Setup.hs configure --ghc --prefix=$doconSource/inst runhaskell Setup.hs build
produces
configuring ... compiling ... ... DPrelude.hs:1:0: Module `DPrelude' is a member of package dumatel-1.2.6.4. To compile this module, please use -ignore-package dumatel-1.2.6.4.
These does exist a package dumatel-1.2.6.4, and both the above packages have DPrelude among the module names. But why does Cabal look into irrelevant package? The dependence is set: only `data'.
This is "fixed" in newer versions of Cabal.
However, you are heading for problems here. When you install a package P that includes a module M, you prevent the user from having any modules called M unless they say '-hide-package P' (see previous discussions on this subject).
For this reason, we strongly recommend using hierarchical module names.
At the moment, Cabal "exposes" all the packages it imports. Perhaps we should have an option to install an unexposed package, to allow installation of packages that contain non-hierarchical module names. Isaac - what do you think?
When you install a package P that includes a module M, you prevent the user from having any modules called M unless they say '-hide-package P'
? First, it is very natural to have several common module names among the installed packages. Suppose the user package P depends on P2, P3. To build P, Cabal finds the minimal needed set S of packages for P. For my particular aforementioned example, this should be sufficient. Because the packages from S occur not to have common module names, and ghc-CVS-current will find this. Right? Now, suppose, for some another example, it occurs a clash: P2 and P3 occur in S and the name DPrelude (.hs) is both in P2 and P3 (and usually these modules have different interface and implementation). Probably, the Cabal system needs to warn about this. But, of course, it is not difficult for Cabal to distinguish these two modules. Because it is visible that one is P2.DPrelude and another is P3.DPrelude. So, before compilation, the modules are resolved. Now, at the compilation stage, it all depends on the import/export set in the modules. And the user may write, for example, like this import qualified P2.DPrelude (f) import qualified P3.DPrelude (f, g) import P4.DPrelude ... Is this "using hierarchical module names" ? On ambiguious interface, the compiler reports as usual. I have impression that the compiler already resolves the module interfaces as needed, and that package processig by Cabal should not add any problem here. If the compiler cannot resolve the import, it asks: " P2.DPrelude or P3.DPrelude ?". The rest is on the user. I thought, the user has also other ways out (as above), besides writing '-hide-package P...'. Is this so? Regards, ----------------- Serge Mechveliani mechvel@botik.