RE: What Cabal stuff is permanent?

On 07 June 2005 14:29, Duncan Coutts wrote:
On Tue, 2005-06-07 at 08:15 -0500, John Goerzen wrote:
On Tue, Jun 07, 2005 at 02:06:34PM +0100, Duncan Coutts wrote:
of this library" through Cabal.
I suspect that any C .h files you need at build time will also be needed by programs which use the library that you are building, since GHC can inline FFI calls across modules in which case the client module needs the .h files when compiling too. And so they should be installed along with your library (assuming it is a library and not a program you're building) and their location mentioned in the .cabal file.
Hmm. I have had several cases where I haven't included these .h files, and things still seem to have worked OK. I do that in MissingPy, for instance. I know that WASH has a .h file that it has not traditionally installed.
You're probably just lucky that GHC decided not to inline the FFI call. :-) (and/or the client module was not being compiled -fvia-C)
You can get the definitive answer as to whether you're on thin ice from one of the GHC devs.
Yes, you're on thin ice. You should assume that any header files required to compile the current module (via C) will be required to compile any module that depends on it. However, if you attach includes to foreign import declarations, like this: foreign import ccall "foo.h bar" bar :: ... then GHC will currently not inline bar in another module. This is a missing feature, and we might fix it at some point. If you use Cabal's "includes" directive, or GHC's -#include option, rather than naming header files in the foreign declaration, then your foreign calls can and will cross module boundaries. You could work around it by not compiling certain modules with -O, or perhaps something funky like {-# OPTIONS_GHC -funfolding-creation-threashold=0 #-} might work (please let us know if it does!). I don't think Cabal currently has support for installing .h files, I guess that's something we need to look into (Isaac?). Cheers, Simon

On Tue, Jun 07, 2005 at 04:04:12PM +0100, Simon Marlow wrote:
However, if you attach includes to foreign import declarations, like this:
foreign import ccall "foo.h bar" bar :: ...
then GHC will currently not inline bar in another module. This is a missing feature, and we might fix it at some point.
Ah ha. That is the only style I've ever used, and is also what WASH uses. So I guess I get out of jail free.
I don't think Cabal currently has support for installing .h files, I guess that's something we need to look into (Isaac?).
Sounds like it. -- John

John Goerzen
On Tue, Jun 07, 2005 at 04:04:12PM +0100, Simon Marlow wrote:
However, if you attach includes to foreign import declarations, like this:
foreign import ccall "foo.h bar" bar :: ...
then GHC will currently not inline bar in another module. This is a missing feature, and we might fix it at some point.
Ah ha. That is the only style I've ever used, and is also what WASH uses. So I guess I get out of jail free.
I don't think Cabal currently has support for installing .h files, I guess that's something we need to look into (Isaac?).
Sounds like it.
How would this look? Let's say that include-dirs=./includes or something relative to the top of the source tree while building. This is so that ghc can find the "includes" while building. include-dirs gets put into ghc's package.conf file, correct? But then will the installed package need an absolute path for include-dirs? Or can it be relative to ghc's library directory or the package root? If the later, it sounds like no big deal, just create the directory and put anything from the "includes" field into it while installing. But then sometimes the include dirs might be an absolute path, maybe? To indicate a .h file that this package is build-depending on? In which case, we might assume that the include files in there are not a part of the package, so we don't try to install them, but they are a dependency and they should be installed on the target system already. If ghc's package.conf file doesn't allow relative paths, then we have to do something a little tricky when generating the package.conf file, which is make up the location that the includes will go. Sounds a little harry, but doable. Does anyone have better ideas? peace, isaac p.s. Lemmih added the ability to build profiling libs to Cabal. Has anyone played with this?

On Tue, Jun 07, 2005 at 08:53:39AM -0700, Isaac Jones wrote:
John Goerzen
writes: I don't think Cabal currently has support for installing .h files, I guess that's something we need to look into (Isaac?).
Sounds like it.
How would this look? Let's say that include-dirs=./includes or something relative to the top of the source tree while building. This is so that ghc can find the "includes" while building.
include-dirs gets put into ghc's package.conf file, correct? But then will the installed package need an absolute path for include-dirs? Or can it be relative to ghc's library directory or the package root? If the later, it sounds like no big deal, just create the directory and put anything from the "includes" field into it while installing.
Hmm. Maybe I lost you, but didn't you mean the "include-dirs" field? I'd say that you should recursively find .h files in the directories specified, and copy them.
But then sometimes the include dirs might be an absolute path, maybe? To indicate a .h file that this package is build-depending on? In which case, we might assume that the include files in there are not a part of the package, so we don't try to install them, but they are a dependency and they should be installed on the target system already.
That makes sense. Or, you could have separate include-dirs-nocopy or something. -- John

On 2005-06-07, Isaac Jones
include-dirs gets put into ghc's package.conf file, correct? But then
While we're at it, it seems that GHC 6.4 no longer has a library-dirs option, and that extra-lib-dirs is *not* installed into the GHC package file. I think that it should be. What do you think? -- John
participants (3)
-
Isaac Jones
-
John Goerzen
-
Simon Marlow