
You are absolutely right, they do not seem to play along very well.
Here's what I tried:
$ cabal install --disable-library-vanilla --enable-shared ranges
Resolving dependencies...
Configuring ranges-0.2.4...
Preprocessing library ranges-0.2.4...
Building ranges-0.2.4...
[1 of 1] Compiling Data.Ranges ( Data/Ranges.hs,
dist/build/Data/Ranges.dyn_o )
Data/Ranges.hs:74:7:
Warning: This binding for `x' shadows the existing binding
bound at Data/Ranges.hs:72:13
cabal: <command line>: Failed to load interface for `Data.Ranges':
Use -v to see a list of the files searched for.
cabal: Error: some packages failed to install:
ranges-0.2.4 failed during the building phase. The exception was:
ExitFailure 1
2011/11/3 Yves Parès
Apparently, disabling library vanilla causes GHC not to generate the ".hi" files : For instance when 'cabal install quickcheck --disable-library-vanilla':
Registering QuickCheck-2.4.1.1... cabal: QuickCheck-2.4.1.1: file Test/QuickCheck/All.hi is missing (use --force to override) QuickCheck-2.4.1.1: file Test/QuickCheck/Function.hi is missing (use --force to override) [...] override) QuickCheck-2.4.1.1: file Test/QuickCheck/State.hi is missing (use --force to override) QuickCheck-2.4.1.1: file Test/QuickCheck/Exception.hi is missing (use --force to override) QuickCheck-2.4.1.1: cannot find libHSQuickCheck-2.4.1.1.a on library path (use --force to override)
2011/11/3 Ivan Perez
2011/11/2 Yves Parès
: Hello,
When I tell cabal-install to build shared libraries (with "Shared: True" in .cabal/config), it doubles the libraries installation time since it compiles them twice, since it seems that is what GHC's flag "-shared" does. Is there a way to generate only the .so and not the the .a libs?
--disable-library-vanilla
Do not build ordinary libraries. This is useful in conjunction with --enable-library-profiling to build only profiling libraries, rather than profiling and ordinary libraries.
Haven't tried it myself. Maybe it works in combination with --enable-shared?
From: http://haskell.org/ghc/docs/7.0.4/html/Cabal/builders.html
Furthermore, I have the impression that the executables compiled by cabal-install are always linked statically... Can I tell cabal-install to activate the GHC's flag "-dynamic" for executables?
The following two trac tickets mention a separate flag, named --enable-executable-dynamic:
http://hackage.haskell.org/trac/hackage/ticket/600 http://hackage.haskell.org/trac/hackage/ticket/869
If that doesn't work, you can probably pass some argument to ghc with --with-ghc-option
Cheers, Ivan
Thanks.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe