D.Program depends on D.Simple.Utils

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Thu Aug 23 09:38:38 EDT 2007

On Thu, 2007-08-23 at 15:10 +0200, Clemens Fruhwirth wrote:

> > 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).

What we do in the InstallDirs module is just to pass the
PackageIdentifier of the compiler rather than passing the Compiler
itself. Then you don't need to import Compiler and there's no cycle :-)

it means callers have to do:

mkSharedLibName blah blah (compilerId (compiler lbi))
ranther than
mkSharedLibName blah blah (compiler lbi)

but that's pretty trivial.


More information about the cabal-devel mailing list