On 28/11/2012 13:13, Ian Lynagh wrote:
My general feeling about Windows is that it's ok for the end result to be a little annoying, because Windows DLLs *are* annoying and it's nothing to do with GHC.
In particular I think in practice most Windows developers will have admin rights and could live with the ghc installation and cabal install having to be done as elevated operations. Where they weren't done with admin rights, then ghc -o could warn the user that the DLLs need to be copied locally (or even copy them itself and tell the user it happened).
Personally, I would prefer the "C stub" option to that.
I think that one would be ok too, but I somewhat prefer SxS simply because of the long-term costs of being non-standard.
More generally, if you can implement the "half a plan" you mentioned elsewhere in the thread for quickly building both static and dynamic ways, then the combination of the ABI and performance issues mean that I'm marginally in favour of keeping static linking as the default for executables on all platforms, but building the dynamic libraries for ghci.
That would solve the "installing libraries takes twice as long" problem, but not the "ghci can't load modules compiled with ghc -c" problem.
Can't ghc -c also produce both static and dynamic objects? I guess only one of the two could be called sourcefile.o Cheers, Ganesh