[Gtk2hs-devel] move Gtk2HsSetup.hs to gtk2hs-buildtools
Claus Reinke
claus.reinke at talk21.com
Thu Nov 25 10:56:58 EST 2010
> 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.html#cpp
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
More information about the Libraries
mailing list