Test Cases for Configurations

[Simon Marlow]

Ian Lynagh wrote:
> On Fri, Jun 15, 2007 at 03:06:07PM +0200, Thomas Schilling wrote:
>> On 15 jun 2007, at 14.09, Neil Mitchell wrote:
>>
>>> this being common practice, and yet permit it occasionally.
>>>
>>> One thing I would like is given a package _data, which provides a data
>>> type, and a package _class which provides a class and various
>>> instances, I'd like to write in the _class cabal file:
>>>
>>> #if has _data
>>>   module Class.InstanceForData
>>> #endif
>>>
>>> Perhaps configurations can support that?
> 
> This has the same problem, in that different versions of the same
> package provide different things.
> 
> Also, if you install _class first and _data second then you don't get
> Class.InstanceForData, whereas installing them the other way round you
> do.
> 
>> Of course in this case we'd need to add some flags to the version  
>> number, to indicate, that tho installed version has a certain feature  
>> enabled.
>>
>> This could be solved with a different package name of course, but I  
>> think it should be easy to add tags to a package version number:
>>
>>   if flag(debug) {
>>     build-depends: hunit
>>     ghc-options: -DDEBUG
>>     tag: debug
>>     exposed-modules: Demo.Internal
>>   }
> 
> One thing I have considered proposing is rather than just
> 
>     exposed-modules: ...
>     other-modules: ...
> 
> we could have (I'm not particularly advocating this syntax):
> 
>     modules: ...
>     modules[testing]: ...
>     modules[internal]: ...

A simpler way to solve this problem is to have two packages, with the first 
package (foo-internal) exporting all the modules, and the second (foo) 
re-exposing just the non-internal modules.  We don't currently have support for 
re-exposing, but it has lots of uses and it shouldn't be too hard to add (to 
GHC, at least).

Perhaps it's not quite as nice, though: the foo-internal package shows up in 
your ghc-pkg list, and you need two separate Cabal packages (although good 
support for working with multiple packages is something we should have too).

Cheers,
	Simon