Proposal: Allow passing in linkable files from TH
moritz at lichtzwerge.de
Tue Oct 3 04:22:47 UTC 2017
I think this would be great to have. Here are few other discussions that have
similar needs but do not necessarily have TH as a direct dependency:
in which aditya siram (deech) asks about linking non-c build objects.
in which Trevor McDonell describes his troubles linking non-c built object
a follow up by deech again, on how to hack this with a custom Setup.hs
Now this is mostly cabal related. But the point I'd like to make is that a
complete solution that includes generating and linking object files from TH
should see if there is a way that this would play nice with cabal as well
(by possibly extending cabal a bit here). This might also tie in with bens
If you could upload your diff to Phabricator, I'd be happy to take a look and
give feedback wrt. to potential cross compilation implications (See also: D3608)
If you have trouble with phabricator, feel free to ask on irc.freenode.net/#ghc
or via email. I'm happy to help out.
> On Oct 3, 2017, at 11:58 AM, Alec Theriault <alec.theriault at gmail.com> wrote:
> I have a TH feature request and I'd like to hear what people have to say about it. Here is the [Trac ticket].
> I'm new to this, so if anything here sounds completely wrong, it probably is.
> TH currently lets you add in arbitrary C (and other languages usually supported by C compilers).
> That code is compiled for you and then linked in automatically. This is what makes the
> [`inline-c`] package possible.
> I'm proposing to extend this so that TH lets you pass in something that is already compiled and
> ready to be linked. The idea is that this would allow TH-level FFI to any language that can
> produce object files or libraries that have the C ABI. My immediate use-case is to make an
> `inline-rust` package where one can write Rust code straight into a Haskell quasiquote.
> In terms of a concrete API change, it would suffice to
> 1. add a `LangLinkable` constructor to the `ForeignSrcLang` data type
> 2. add a `qAddForeignFilePath :: ForeignSrcLang -> FilePath -> m ()` method to `Quasi`
> The code change is pretty small too (60 additions, 30 deletions) since the `addForeignFile`
> machinery is fully reusable (we just have to skip past the phase of calling the C compiler).
> # Pros:
> * Better TH FFI support
> * Simple to implement
> # Cons:
> * The proposed API is suboptimal: it allows for `qAddForeignFile LangLinkable "..."` although that
> that pretty much never makes sense since the thing being linked is not subject to `String` encoding
> Any thoughts?
> : https://ghc.haskell.org/trac/ghc/ticket/14298
> : https://hackage.haskell.org/package/inline-c
> ghc-devs mailing list
> ghc-devs at haskell.org
More information about the ghc-devs