How to specify foreign import headers

[phadej]

For CApiFFI we need to include a header for declrations, e.g.

foreign import capi "header.h foo" foo :: Int -> IO ()

However, with file-processing interface we don't know what's the canonical import. Is it some-header.h or clang-c/Index.h (i.e. whether to drop directories or not).

How to solve this?

Note: rust-bindgen doesn't have such problem as it doesn't have CApiFFI like system. If we use ordinary ForeignFunctionInterface, then the linker will find symbol, so

• if we use CApiFFI, should user specify how to import the header?
• Or should we not use capi (but then we need to at least care about calling conventions)

[TravisCardwell]

My understanding is that users should specify header files using paths that are relative to an include directory, in which case we generate CApiFFI directives using the passed include file path (including any directory names).

For the libclang example, pkgconf sets include directory /usr/include (on my system), so clang-c/Index.h successfully references /usr/include/clang-c/Index.h.

When manually configuring, users should configure both include-dirs and install-includes in the .cabal file, where include files may be relative to an include directory. Users should then specify the header file to translate as it is specified in install-includes.

Am I missing or misunderstanding anything?

[phadej]

I'm not fan of looking up extra information (system include paths, Cabal includes) if the opposite cost is just make user specify a bit more information.

I think it will clarify when hs-bindgen usage, speficially as preprocessor in Cabal is fleshed out. Until then doing the simplest thing feels best.

[TravisCardwell]

A quick clarification: in my understanding described above, it is up to the user to specify include directories relative to include paths (as configured by pkgconfig or manually in their .cabal file). In our implementation, we do not have to query system include paths for Cabal configuration; we simply use the relative include paths that users specify.

[phadej]

@TravisCardwell even if understand you, my point stands:

think it will clarify when hs-bindgen usage, speficially as preprocessor in Cabal is fleshed out.

For TH usage nothing you said really make much sense, users would need to specify where to find the file, but also how include it from C anyway (and the latter may have a default for common cases).

It might also make sense to always require some kind of wrapper header (so it's file local to package), even if it's literally just #include <something>. That would require #294 in someway, SelectFromMainFile won't work then.

[phadej]

TL;DR I think it's time to work towards the real example, not just golden-fixture runs in our test-suite. There is a very simple TH test, and that can be extended; but Cabal/preprocessor usage is completely unexplored.

[TravisCardwell]

👍

We should probably test against real examples using pkgconf as well as manual configuration. My impression is that manual configuration keeps things simple when doing so is possible, while pkgconf is desired when the C code has (non-trivial) dependencies.

When using pkgconf for local C code, I found that I had to configure environment variables. Building required setting PKG_CONFIG_PATH to find the header, while executing required setting LD_LIBRARY_PATH to find the dynamically-linked shared object file.

[edsko]

Related to #71 .