[Gtk2hs-devel] move Gtk2HsSetup.hs to gtk2hs-buildtools

[Axel Simon]

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