cabal

How to make a Haskell cabal project with library+executables that still run with runhaskell/ghci?

人盡茶涼 提交于 2019-11-26 23:56:39
问题 If you declare a library + executable sections in a cabal file while avoiding double compilation of the library by putting the library into a hs-source-dirs directory, you cannot usually run your project with ghci and runhaskell anymore, especially if the executables have helper modules themselves. What is a recommended project layout that only builds what is needed once allows using runhaskell has a clean structure without hacks? 回答1: Let's assume you have a mylib library, and mylib

Cabal not installing dependencies when needing profiling libraries?

混江龙づ霸主 提交于 2019-11-26 21:58:34
I want to compile my program with profiling, so I run: $ cabal configure --enable-executable-profiling ... $ cabal build ... Could not find module 'Graphics.UI.GLUT': Perhaps you havent installed the profiling libraries for package 'GLUT-2.2.2.0'? ... $ # indeed I have not installed the prof libs for GLUT, so.. $ cabal install -p GLUT --reinstall ... Could not find module 'Graphics.Rendering.OpenGL': Perhaps you havent installed the profiling libraries for package 'OpenGL-2.4.0.1'? ... So, the problem is, that unlike cabal's usual welcome behavior, cabal doesn't resolve the dependencies and

Statically link GMP to an Haskell application using GHC (+ LLVM)

前提是你 提交于 2019-11-26 20:14:15
问题 How can I drop dynamic dependency on libgmp and go from this: linux-vdso.so.1 => (0x00007fffdccb1000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fb01afc1000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb01acc7000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fb01aabe000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb01a8ba000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb01a69d000) libc.so.6 => /lib/x86_64-linux-gnu/libc