Hi Claus, On Nov 25, 2010, at 18:43, Claus Reinke wrote:
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.
I think this is a hack. For instance, it means that any application that uses any Gtk2Hs package would depend on gtk2hs-buildtools which is not really true and unnecessary. Does one really want extra executables (aka the build tools) lying around for any Gtk2Hs application? I think not. This is the case at the moment, but I think cabal should have the ability to install build tools for a package and possibly even remove them once the package has been built.
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.
Does that work in Setup.hs? I thought that these CPP macros were generated by the 'confgure' step, which may not have been run yet.
argh. You're right - the macros are not available in Setup.hs. I keep forgetting that because it would be useful to have them there
http://hackage.haskell.org/trac/hackage/ticket/326
So, if putting the file into the tools package doesn't suffice, we'd be back to passing in CPP macros from .cabal files (or using a front Setup.hs to check the configuration info before calling out to a version-specific SetupX.hs).
I tend to think that a recursive call to a different Setup.hs would be the best solution. The question is what features must be available in the outer Setup (checking for installed packages and being able to install those that are missing, for example) and which ones do we only need in the inner Setup (knowing the exact cabal version). Regards, Axel