On 2 December 2011 07:19, Edward Z. Yang ezy...@mit.edu 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
-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 ezy...@mit.edu wrote:
Hello folks
On 2 December 2011 12:21, Chris Dornan ch...@chrisdornan.com 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
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 I am sure if I have
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 this package provides
-
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 virtual
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
