On 24 April 2006 15:08, kahl@cas.mcmaster.ca wrote:
Perhaps (just a quick first attempt to get the idea across):
{-# INCLUDE_PRIVATE "foo/bar.h" "foobar.o" #-} {-# INCLUDE_PACKAGE "foo/bar.h" "-lfoobar" #-}
I would have considered allowing just
{-# INCLUDE_PRIVATE "foo/bar.h" "foobar" #-}
I understand your reasoning, but I think it's wrong to name libraries in the source code. Library names tend to be platform specific, and change from version to version. Unlike header files, the package implementer can't easily wrap a library dependency in a local library.
By the way, I do not think that an implementation necessarily has to avoid inlining of limited imports; I think it also could choose to keep the necessary information around in the hidden parts of the package. Users of the package just cannot add foreign imports using those .h files, in the same way as they cannot import hidden Haskell modules.
The issue is whether the .h file is available to the client at all. Making it available might impose an unnecessary burden on the client, such as having to install a development package for an external library. Actually it just occurred to me why using NOINLINE isn't the right thing here. The compiler should be free to inline a foreign call that depends on a private header, as long as the header isn't required for compilation, such as when using the native code generator. Cheers, Simon