You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To properly support c2hs in Cabal we need a couple enhancements:
dependency resolution.
Not only do the .hs files depend on the .chs files but .chs files can depend on other .chs files (or strictly speaking on their corresponding .chi files).
This is because c2hs supports its own module import mechanism to get information about bindings defined in one module to be used in other modules.
If the compiled binding module contains import hooks, C->Haskell needs to
find the .chi (C->Haskell interface files) produced while compiling the
corresponding binding modules. By default, they will be searched for in
the current working directory. If they are located elsewhere, the
--include=INCLUDE option has to be used to indicate the location, where
INCLUDE is a colon-separated list of directories. Multiple such options
are admissible. Paths specified later are searched first.
The Gtk2Hs project has a [script](http://darcs.haskell.org/gtk2hs/mk/chsDepend.in) to find the dependencies of a .chs file. This should be translated into Haskell and included in Cabal's future pluggable dependency resolution mechanism(!).
The .chi files need to be installed
If one Cabal package uses .chs files then another package that wants to import that module into another .chs module using c2hs's import mechanism will need access to the .chi file of the imported module. This is basically the same as how ghc needs the .hi file of imported modules.
One difference is that .chi modules are transitive (unlike ghc's .hi files) so only the .chi files corresponding to exposed modules need to be installed (where as for ghc every .hi file needs to be installed).
Both of these enhancements are essential to be able to package Gtk2Hs using Cabal. Gtk2Hs has many .chs modules and with dependencies between them, including many dependencies between .chs modules in different packages. For example all of the Gtk+ extension packages (OpenGL, SourceView, Glade, Mozilla embeding widget) import type definitions from .chs modules in the base gtk & glib packages.
The text was updated successfully, but these errors were encountered:
We're cleaning up the bug tracker to make it useful again and are thus closing bugs that haven't seen any activity in a long time. Please re-open (or file a new bug) if the problem reappears.
(Imported from Trac #48, reported by @dcoutts on 2006-01-16)
To properly support c2hs in Cabal we need a couple enhancements:
Not only do the .hs files depend on the .chs files but .chs files can depend on other .chs files (or strictly speaking on their corresponding .chi files).
This is because c2hs supports its own module import mechanism to get information about bindings defined in one module to be used in other modules.
From the c2hs manual:
The Gtk2Hs project has a [script](http://darcs.haskell.org/gtk2hs/mk/chsDepend.in) to find the dependencies of a .chs file. This should be translated into Haskell and included in Cabal's future pluggable dependency resolution mechanism(!).If one Cabal package uses .chs files then another package that wants to import that module into another .chs module using c2hs's import mechanism will need access to the .chi file of the imported module. This is basically the same as how ghc needs the .hi file of imported modules.
One difference is that .chi modules are transitive (unlike ghc's .hi files) so only the .chi files corresponding to exposed modules need to be installed (where as for ghc every .hi file needs to be installed).
Both of these enhancements are essential to be able to package Gtk2Hs using Cabal. Gtk2Hs has many .chs modules and with dependencies between them, including many dependencies between .chs modules in different packages. For example all of the Gtk+ extension packages (OpenGL, SourceView, Glade, Mozilla embeding widget) import type definitions from .chs modules in the base gtk & glib packages.
The text was updated successfully, but these errors were encountered: