Skip to content

improve c2hs support #55

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
bos opened this issue May 24, 2012 · 4 comments
Closed

improve c2hs support #55

bos opened this issue May 24, 2012 · 4 comments

Comments

@bos
Copy link
Contributor

bos commented May 24, 2012

(Imported from Trac #48, reported by @dcoutts on 2006-01-16)

To properly support c2hs in Cabal we need a couple enhancements:

  1. 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.

From the c2hs manual:

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(!).
  1. 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.

@bos
Copy link
Contributor Author

bos commented May 24, 2012

(Imported comment by @dcoutts on 2006-01-16)

Depends on #15

@bos
Copy link
Contributor Author

bos commented May 24, 2012

(Imported comment by guest on 2007-11-21)

c2hs doesn't seem to get passed the extra-include-dirs values, either. Works fine for include-dirs, so it's only a minor wart.

@bos
Copy link
Contributor Author

bos commented May 24, 2012

(Imported comment by @dcoutts on 2009-09-30)

Replying to guest:

c2hs doesn't seem to get passed the extra-include-dirs values, either. Works fine for include-dirs, so it's only a minor wart.

This probably wants to be filed as a separate bug. It's much easier to fix than the problem this ticket is about.

@tibbe
Copy link
Member

tibbe commented May 5, 2014

Closing as there's been no activity in years.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants