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
Could it become a convention that tool packages install a library with tool paths (and other relevant configuration data)? Similar to ghc-paths. That way, the tool would be represented in the package database, and the paths would make use and configuration in dependent packages simpler.
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.
There is MIN_VERSION_<package>(), so you might be able to check whether it is defined/has the right version, if it comes with the tools package. http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/authors.ht... But, if the setup library is part of the tools package, and the latter becomes a dependency, wouldn't cabal install take care of that bit? Claus
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