This kills a few typos and makes things more consistent
with more #haskell discussion.
build-depends := bexp
bexp := package-with-version
| cexp '?' '(' bexp ')'
| bexp ',' bexp
configuration := 'configuration:' cexp
cexp := '(' cexp ')'
| cexp '||' cexp
| cexp '&&' cexp
And here is the newest after discussion with Duncan Coutts on
#haskell.
build-depends := bexp
bexp = package-name-with-version
| '(' bexp ')'
| cexp '?' bexp
| bexp ',' bexp
| 'T'
configuration := cexp
cexp = '(' cexp ')'
| cexp '|' cexp
| cexp '&' cexp
| 'T'
On Thu, 2006-08-10 at 22:13 +0100, Duncan Coutts wrote:
> So, with this in mind, can we come up with a syntax & semantics that is
> close to our current configurations proposals but is not evil?
One thing that might help is if we split the 'package' condional test
into two distinct things.
I thi
I was also talking to the Gentoo protage developers about this. They had
a couple interesting points.
They say that automatically picking up optional dependencies is bad,
even if they are tracked. That there must be a way to build without some
dep even if it's installed and available. eg to build
Hello
This is a formulation after more discussion on #haskell.
This is for build-depends with the configurable things.
Not sure whether this is the best way.
- Einar Karttunen
bexp = package-with-version
| '(' bexp ')'
| bexp '|' bexp
| bexp ',' bexp
| 'Flag(' string ')'
Following long discussions on #haskell, here's some tricky cases we
thought of with configurations.
1.
build-depends: base
configuration: debug
build-depends: HUnit>=1.0
configuration: package(HUnit>=1.1)
ghc-options: -DBlah
The issue with this is what the "package(HUnit)" test means. Under o
On Thu, 2006-08-10 at 19:31 +0300, Einar Karttunen wrote:
> Hello
>
> There was a discussion about the semantics of the package
> dependencies on #haskell. Continuing here for clarity.
>
> build-depends: foo > 1 && < 3
> vs
> build-depends: foo > 1, foo < 3
>
> and the same with configuration st
Heya Simon.
I've noticed that in ghc 6.4.2, ghc-pkg doesn't create the file (or
maybe just the directory) when trying to register a package:
rm -r ~/.ghc/i386-linux-6.4.2
/usr/bin/ghc-pkg update .installed-pkg-config --user
ghc-pkg.bin: /home/ijones/.ghc/i386-linux-6.4.2/package.conf: getPermiss
Hello
There was a discussion about the semantics of the package
dependencies on #haskell. Continuing here for clarity.
build-depends: foo > 1 && < 3
vs
build-depends: foo > 1, foo < 3
and the same with configuration stuff:
packages(foo >1 && < 3)
vs
packages(foo > 1) && packages(foo < 3)
Curr
Added compiler support and fixed a missing file from darcs.
- Einar Karttunen
configurations4.patch.gz
Description: Binary data
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Next version - changes:
* fix multiple enables conflicting with each other
* add test-case
- Einar Karttunen
configurations3.patch.gz
Description: Binary data
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/
On 10.08 06:04, Einar Karttunen wrote:
> On 02.08 11:11, Simon Marlow wrote:
> > A little bit more about configurations. Here's what you can do with them:
>
> Implemented parts of the spec. I wish for this to get into 6.6
> to avoid problems e.g. depending on fps. This is alpha quality
> code, bu
Esa Ilari Vuokko wrote:
On 8/9/06, Isaac Jones <[EMAIL PROTECTED]> wrote:
"Neil Mitchell" <[EMAIL PROTECTED]> writes:
> I'm interested in using Cabal to build the base library, just like any
> other library. Does this have any chance of working? How much work
> would it take?
I thought this a
13 matches
Mail list logo
