If this does happen, it'd probably make sense to use this as a chance to refactor out the LLVM bits and use the llvm-general package. llvm-general seems to only depend on base libraries (apart from parsec, which seems to only be used for parsing data layout formats; it could probably be disabled with a compiler flag if we construct the data layout structures directly; see https://github.com/bscarlet/llvm-general/blob/5f266db5ad8015f7d79374684b083ffdeed3c245/llvm-general-pure/src/LLVM/General/DataLayout.hs). It seems a more principled way than what is currently implemented, and work done to improve that library via ghc would also help every other user of the library, and visa versa.
On 27 October 2014 19:25, Sergei Trofimovich <sly...@gmail.com> wrote: > On Fri, 24 Oct 2014 18:52:53 -0500 > Austin Seipp <aus...@well-typed.com> wrote: > > > I won't repeat what's on the wiki page too much, but the TL;DR version > > is: we should start packaging a version of LLVM, and shipping it with > > e.g. binary distributions of GHC. It's just a lot better for everyone. > > > > I know we're normally fairly hesitant about things like this (shipping > > external dependencies), but I think it's the only sane thing to do > > here, and the situation is fairly unique in that it's not actually > > very complicated to implement or support, I think. > > That makes a lot of sense! Gentoo allows user > upgrade llvm and ghc independently, which makes > syncing harder. Thus Gentoo does not care much > about llvm support in ghc. > > -- > > Sergei > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
