-
From: Edward Z. Yang [mailto:ezy...@mit.edu]
Sent: 02 December 2011 16:31
To: Chris Dornan
Cc: Duncan Coutts; cabal-devel
Subject: RE: Virtual packages and subpackages
There are two closely related features here (both of which could be useful.)
This wasn't helped by me mixing up vi
There are two closely related features here (both of which could be useful.)
This wasn't helped by me mixing up virtual packages with subpackages (which I
think is actually what I wanted.) Here's the relevant quotes:
"Provides:" lets you list virtual package names that t
I thought the idea was to allow a single cabal file to be able to generate
multiple packages -- the primary package which shares the name of the cabal
file and several 'virtual' packages, each with different permutations of the
'options' flags.
Edward will correct me
On 2 December 2011 12:21, Chris Dornan wrote:
> Indeed it looks like a mechanism for making multiple packages easier to
> manage -- rather like RPM provides (from which the terminology is borrowed I
> think).
>
> It sounds like a really good idea and surely the best way of removing the
> pressu
-Original Message-
From: cabal-devel-boun...@haskell.org [mailto:cabal-devel-boun...@haskell.org]
On Behalf Of Duncan Coutts
Sent: 02 December 2011 11:52
To: Edward Z. Yang
Cc: cabal-devel
Subject: Re: Virtual packages
On 2 December 2011 07:19, Edward Z. Yang wrote:
> Hello folks,
>
&
On 2 December 2011 07:19, Edward Z. Yang wrote:
> Hello folks,
>
> I was thinking a little about how build flags that modify functionality
> are harmful for dependency resolution (pandoc and xmobar, I'm glaring at you),
> but authors will still use this feature because it's a lot easier than
> ma
Hello folks,
I was thinking a little about how build flags that modify functionality
are harmful for dependency resolution (pandoc and xmobar, I'm glaring at you),
but authors will still use this feature because it's a lot easier than
maintaining
a bunch of separate packages for each different fl
