runghc and linking in libraries
If I want to have (and run without explicitly invoking ghc or runghc) a script that starts as follows: #!/usr/bin/runghc module Main where import MyLib I can do it just fine if MyLib is a pure-haskell MyLib.hs -- it doesn't have to be packaged or installed or anything complicated. If I want to create a MyLib that uses C code (that I wrote) through FFI, it doesn't seem to be possible to use it in a runghc script like this, unless I create a package and install it. Am I correct about this? In the course of researching this, I realized that I have a rather poor understanding of what "packages" are in ghc-land. I have a high-level-overview understanding ("It's like rubygems, but for haskell"), but I'm rather unclear about the nuts-and-bolts of it. The tight coupling between packages and the ghc core is rather different than what I've seen in other programming languages I've used (I haven't programmed in Java though) It would be useful if ghc had an argument to take a "MyLib.lib" file (or maybe a directory) and temporarily act like it's an installed package for the one invocation. Unsurprisingly, web-searching for "haskell" and "package" doesn't give me the focused result set that I want. I found the relevant section of the GHC Users Guide https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.htm... but links to other reading materials would be appreciated.
On Thu, Jul 20, 2017 at 2:25 AM, Brian Sammon < haskell-cafe@brisammon.fastmail.fm> wrote:
If I want to create a MyLib that uses C code (that I wrote) through FFI, it doesn't seem to be possible to use it in a runghc script like this, unless I create a package and install it. Am I correct about this?
You would have to explicitly link it in: runghc Foo.hs bar.o (or -lbar if it's a library). It's not really designed for anything larger than a single source file without non-package dependencies. In the course of researching this, I realized that I have a rather poor
understanding of what "packages" are in ghc-land. I have a high-level-overview understanding ("It's like rubygems, but for haskell"), but I'm rather unclear about the nuts-and-bolts of it. The tight coupling between packages and the ghc core is rather different than what I've seen in other programming languages I've used (I haven't programmed in Java though)
Have you programmed in C, especially with heavy use of inline or CPP? The cause of the tight dependencies is that ghc inlines a lot of things, even across modules; which means that even parts of a module that aren't explicitly exported are generally visible for inlining. And performance will suck if you defeat this. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
participants (2)
-
Brandon Allbery -
Brian Sammon