package installation woes with Template Haskell / dynamic libraries

[Richard Eisenberg]

Hi all,

---
tl;dr: cabal fails to install a package where one module in the package uses another module via Template Haskell, requiring a .dyn_o file. The compilation order, though, makes .o files before .dyn_o files, so installation fails. Is this my fault or cabal's?
---

I've built and installed HEAD (as of Apr 8), on Mac OS 10.8.2, without specifying a build.mk file (i.e., using the defaults). I then tried to install the singletons package. This package has multiple modules, one of which uses another in some Template Haskell code. The TH code also uses the syb and mtl packages.

- A simple `cabal install singletons` fails when compiling the module that uses TH, because there are no .dylib files for the syb or mtl libraries. I add 'shared: True' to my ~/.cabal/config file, "dangerous"ly reinstall mtl and syb and try again.

- Now, `cabal install singletons` still fails during compilation, because the TH code looks for Singletons.dyn_o, which doesn't exist. The problem is that the vanilla build happens before the shared build, and TH seems to require the shared build.

- I try `cabal install singletons --disable-library-vanilla`, and everything compiles, but then I get this:

Installing library in
/Users/rae/Library/Haskell/ghc-7.7.20130407/lib/singletons-0.8.5/lib
cabal: dist/build/HSsingletons-0.8.5.o: does not exist

- In the hopes that cabal kept the .dyn_o files around, I try regular `cabal install singletons`, but cabal seems to have discarded the .dyn_o files and I get the same error as before.

- So, I `cabal unpack singletons`, go into the singletons folder, and run `cabal install --disable-library-vanilla`, and get the installation error as before. But, the compile worked and the .dyn_o files are kept! So, a final `cabal install` now works. Phew.

I have a relatively weak understanding of cabal. My question is: Is the problem I've run into here based on local settings that need to be fixed? Is there a moving part somewhere that needs to be upgraded? Or, is this a real bug somewhere? If the problem isn't local, I see three separate bugs here:

1) I had to "dangerous"ly reinstall mtl and syb to get the shared libraries after updating my ~/.cabal/config. I think it should be possible to augment an existing package installation with a new "way" without reinstalling.

2) If a package uses TH and depends on another package, and if TH requires dynamic linking, cabal should automatically install dynamic versions of the library, overriding settings in ~/.cabal/config. Or, if overriding settings is a no-no, it should give a stern warning. It would make sense if this dependency were required to be stated in the package's .cabal file.

3) If a package uses TH and depends on itself, similar logic should apply (requiring a dynamic build), and the order of compilation should be fixed.

I can understand (but, without more knowledge, would disagree with) an argument discarding 1) and 2) as natural consequences of a silly user, but 3) -- especially the compilation order -- seems more fundamental. I don't know of a way of installing singletons now without unpacking it and dancing around this problem.

What do you think? Are these bugs? Am I a silly user? Or both?

Thanks!
Richard