
Dear Libraries, this message is on shortcomings of cabal with respect to automatically installing the gtk package which (a) depends on a package that contains only build tools (i.e. only binaries) and (b) has a big custom Haskell file Gtk2HsSetup.hs that Setup.hs has to import (and which is required in any package in the Gtk2Hs suite). This file is copied into every package of the Gtk2Hs suite which is a pain to maintain. On 25.11.2010, at 10:50, Lazycat Manatee wrote:
---------- Forwarded message ---------- From: Jens Petersen
Date: 2010/11/25 Subject: Re: [Gtk2hs-devel] move Gtk2HsSetup.hs to gtk2hs-buildtools To: Andy Stewart Jens Petersen
writes: I suggest moving Gtk2HsSetup.hs into a library, it could be part of gtk2hs-buildtools perhaps. How about it? It can't work.
Because we need Gtk2HsSetup.hs generate Signals.chs and Types.chs *before* any cabal depend check.
Hmm I haven't tested but don't really understand. You mean it will break builds with cabal-install? Doesn't gtk2hs-buildtools already do that? :)
Yes, but these are two separate show-stoppers: a) the gtk2hs-buildtools contains only binaries. It does not register as a package with ghc. Thus, if we make the gtk package depend on gtk2hs-buildtools, cabal would complain that (even after installing gtk2hs-buildtools) the gtk2hs-buildtools library is not there b) putting Gtk2HsSetup.hs in either gtk2hs-buildtools or any other library means that ./Setup.hs has to run to realize that this library is missing and that it needs to be downloaded. However, ./Setup.hs cannot be run because it imports Gtk2HsSetup.hs which is not yet available. I don't know if (b) can be solved by e.g. conditionally importing Gtk2HsSetup.hs if it is there and only installing libraries and re- invoking Setup.hs one this is done. This is a common trick in Makefiles, e.g. one could call make recursively to first build dependencies. Any suggestions welcome. Regards, Axel