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 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
