[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