D.Program depends on D.Simple.Utils

Clemens Fruhwirth clemens at endorphin.org
Thu Aug 23 09:10:57 EDT 2007


At Thu, 23 Aug 2007 13:32:02 +0100,
Duncan Coutts <duncan.coutts at worc.ox.ac.uk> wrote:
> 
> On Thu, 2007-08-23 at 11:57 +0200, Clemens Fruhwirth wrote:
> > Hi,
> > 
> > I was about to extend Dist.Simple.Utils with a method called
> > mkSharedLibName, which depends on Compiler information, hence
> > Dist.Simple.Utils was about to import Dist.Compiler. I ran into this
> > dependency loop:
> > 
> > Module imports form a cycle for modules:
> >   Cabal-1.1.7:Distribution.Compiler
> >     imports: <..> Distribution.Program <...>
> >   Cabal-1.1.7:Distribution.Program
> >     imports: <..> Distribution.Simple.Utils <..>
> >   Cabal-1.1.7:Distribution.Simple.Utils
> >     imports: <..> Distribution.Compiler <..>
> > make: *** [.depend] Error 1
> > 
> > After a short discussion on #ghc, Esa Ilari Vuokko explained that
> > Dist.* is not supposed to depend on Dist.Simple.*, so it seems
> > reasonable to break the dependency cycle at "Program -> Simple.Utils".
> 
> Actually, I think Program and Compiler (though perhaps not
> CompilerFlavour) should move under Simple. These two modules are
> intimately connected with the simple build system, they're not just
> declarative information like the rest of Distribution.*

Ok, fine.

> So then it'd be ok for them to use Utils. If mkSharedLibName needs
> Program then I don't think  should go in Utils. Why does it need
> Program?

This is the 'offending' patch http://hpaste.org/2384.

Sniplet:
-- Implement proper name mangling for dynamical shared objects
-- libHS<packagename>-<compilerFlavour><compilerVersion>
-- e.g. libHSbase-2.1-ghc6.6.1.so
mkSharedLibName :: FilePath -- ^file Prefix
              -> String   -- ^library name.
              -> Compiler -- get the compiler version
              -> String
mkSharedLibName pref lib comp = pref </> ("libHS" ++ lib ++ "-" ++ (compilerDSOTag comp) ++ (showVersion (compilerVersion comp)) ++ ".so")

It makes use of compiler information, because we decided to mangle the
compiler name and compiler version into the library name. The compiler
name is obtained by compilerDSOTag (dynamic shared object tag) and the
name is simply the printed representation of the compiler version.  (I
still need to add a proper parametrization for the extension;
.dll/.dylib/.so).

But the suggested move from Compiler to Simple.Compiler does not break
the cycle, as Simple.Compiler depends on Program, which depends on
Simple.Utils which because of my change depends on Simple.Compiler.

We could move the filename generating functions to a different module
(InstallDir) and evade the problem, but I guess that's not what we
want to do. (but it's fine with me, as I can proceed with my agenda of
dynamic library support in cabal)
--
Fruhwirth Clemens - http://clemens.endorphin.org 





More information about the cabal-devel mailing list