- cabal-devel - Haskell.org

Re: [Haskell-cafe] Cabal ^M bug
by Brian Smith 19 Nov '06

19 Nov '06

The password is haskell' (notice the apostrophe at the end). I think the password should be changed to something easier to read. Also, I can confirm that this is a bug because I have run into it myself. - Brian On 11/18/06, Vyacheslav Akhmechet <coffeemug(a)gmail.com> wrote: > > Cabal appears to have an end-of-line bug. If the .cabal file is > created on Windows and the project is installed on a Unix system, the > resulting executable ends up having ^M at the end because Cabal > doesn't properly handle Windows line termination. If the .cabal file > is converted to Unix style, everything installs as expected. > > I tried to submit a ticket to Cabal via the wiki but couldn't > authenticate (guest/haskell, as says on the web page, doesn't seem to > work). Also HackageDB link seems to be down. I'm not sure who's > maintaining the project, so I'm emaling here. > > Thanks, > - Slava. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

"putting" packages compatible with ghc 6.6
by Isaac Jones 15 Nov '06

15 Nov '06

I'm working on building a set of packages that are known to be compatible with GHC 6.6: http://hackage.haskell.org/packages/testing-6.6/ I'm working on a script to download and install haskell packages (from unstable), and if they build, install them into "testing". I tweaked "cabal-put" (on monk) to accept a new parameter, so you can now say: cabal-put foo-1.1.tar.gz unstable or cabal-put foo-1.1.tar.gz testing So... if you have permission on monk, please cabal-put your packages into the repository, and if you can test it with ghc 6.6, put it into testing :) This script, cabal-builder (OK, bad name) is in the cabal repository that has cabal-install: http://darcs.haskell.org/cabal-with-install/ peace, isaac

2 2

Cabal vs Hugs
by Neil Mitchell 15 Nov '06

15 Nov '06

Hi, (Not sure if this should go down the hugs list or the Cabal one, so taking a wild guess). Trying to install a Haskell package: C:\Neil\cabaly\safe>runhugs Setup configure runhugs: Error occurred ERROR "C:\Program Files\WinHugs\packages\base\Text\ParserCombinators\ReadP.hs":1 56 - Syntax error in type expression (unexpected `.') I know the reason for this is because ReadP uses a forall type, which hugs doesn't parse without the -98 flag. runhugs -98 Setup configure works just fine. Sadly thats not the best possible user experience - is there anything better that can be done? Does Cabal absolutely require ReadP? Thanks Neil

2 1

On why 'available' is evil
by Duncan Coutts 09 Nov '06

09 Nov '06

In all this discussion on configurations I think I'm not getting over my main point about why we can't go for the 'easy' option of allowing package 'available' tests everywhere. Let me list a few reasons and then expand on them. 1. it often doesn't mean what you want 2. it allows auto-use deps 3. it makes life hard for distros and cabal-get 4. it makes the install order significant So, 1: it often doesn't mean what you want configuration: available(foo >= 2) cpp-options: -Denable_cool_feature There's no necessary relation between what packages are available in the environment and the one(s) that the package is going to be built against. So the above will fail if we actually build with foo-1 but foo-2 is available. What's worse is that it will likely work on the developers machine but fail on the users machine. 2: it allows auto-use deps An auto-use dep is one where we add an extra dependency on a package just because it's available. This is bad for a number of reasons. It means you cannot build a package on one machine and distribute it on another if that other doesn't have the optional dependency (the only way to do it would be to delete the optional package on the build machine). Distros do not support this kind of dep. It mostly makes no sense in binary-based distros and is actively banned in source distros like gentoo: http://www.gentoo.org/proj/en/qa/automagic.xml Indeed this kind of dependency cannot even be expressed in gentoo's dependency syntax. 3: it makes life hard for distros and cabal-get So how is cabal-get supposed to decide before hand all the dependencies that are needed to install a set of packages. Suppose we want to install A and B, but B checks if A is available and if so depends on C. So cabal-get needs to figure out the order it's going to install things and forward-propagate the set of installed packages at that time to figure out if an extra dep on C will be needed or not. As I mentioned already, many distros cannot express these kinds of automatic optional dependencies and so they will have to be turned into hard dependencies or eliminated by the distro package authors. This is a lot more work for them than if the translation is straightforward and can be automated. 4: it makes the install order significant in the above example, we only need C if we install A then B. If we install B then A, then we do not need C. So the order that we install becomes significant. We might be able to make cabal-get always choose one order (at the expense of preventing parallel builds) but that's not necessarily the same order that a distro package manager will pick. This isn't that bad but it's not exactly nice or intuitive. Duncan

4 3

Solaris LD bug for cabal
by Isaac Jones 09 Nov '06

09 Nov '06

Hi Christian, I'm forwarding this to the cabal list :) Does anyone know how to detect this case? pax

1 0

Cabal + WinHugs + Windows + No C Compiler
by Neil Mitchell 08 Nov '06

08 Nov '06

Hi, I want to shove Hoogle's databases in to the appropriate Path's place, as Cabal tells me. However, I also want to develop Hoogle using WinHugs on Windows on a computer without a C compiler, and it seems that the generated Paths_Hoogle module requires FFI on Windows? Is there any way round this, or am I just out of luck in using Cabal's path feature in this situation? Thanks Neil

5 18

Bug: Cabal + Windows + extensions on executables
by Neil Mitchell 08 Nov '06

08 Nov '06

Hi With Hoogle, I have as one of the lines: Executable: index.cgi Main-Is: Web.hs Other-Modules: HTML Hs-Source-Dirs: src, src/Web This generates a file called index.cgi However, I don't think that install realises this... D:\sources\hoogle>runhaskell Setup install Installing: C:\Program Files\Haskell\Hoogle-3.0\ghc-6.4.2 & C:\Program Files\Has kell\bin Hoogle-3.0... *** Exception: dist\build\index.cgi\index.cgi.exe: copyFile: does not exist (No such file or directory) Windows XP, GHC 6.4.2, Cabal from darcs Thanks Neil

2 2

[Otakar Smrz] Cabal's `sdist` on Win32
by Isaac Jones 02 Nov '06

02 Nov '06

Can any windows folks vet this idea? peace, isaac

4 6

Configurations proposal
by Duncan Coutts 01 Nov '06

01 Nov '06

Hi All, Before the 6.6 release we had a longish discussion on how to do configurations and their semantics and implementation complexity etc. I would like to re-propose the last scheme that I cam up with. I'll try to make it a concrete proposal as well as giving some motivating examples to give the intuition of the meaning. Key points: It's crucial that the user / packaging system have control over optional aspects of configuration. For example it is verboten for a package to just inspect the current environment and decide to use a package just because it's available without the user getting any say in that decision. (Eg a user might want to build a package to depoly on another system where that optional package is not available). What it certainly allowed is for a package to state conditional dependencies, that is a package may say: "if you, the user, force me to build using base-1.0 then I absolutely require fps-0.8". So the user / packager must have complete control over the environment that the package sees. On the other hand, for convenience it's ok for the default decision about these optional things to depend on what's available, the os or whatever. It's just important that any defaults be overrideable. So that motivates a design that separates decisions based on the environment from conditional requirements that are intrinsic and independent of the environment. So I propose two kinds of stanza: flags and configurations. flag ::= "flag:" name "default:" fexp fexp ::= "available"( dependency ) | "os"( STRING ) | "arch"( STRING ) | fexp || fexp | fexp && fexp | !fexp | True | False conf ::= "configuration:" cexp fields cexp ::= "flag"( STRING ) | "using"( dependency ) | "os"( STRING ) | "arch"( STRING ) | cexp || cexp | cexp && cexp | !cexp | True | False So flag default values can depend on what packages are available in the environment. There's no restriction on the packages that are named. The default value may also depend on the OS and architecture the package is being configured for. (We should consider splitting this into host and target arch). The idea is that these named flags turn into user tweakable settings but with sensible default values. For example they might turn into check buttons in an IDE or --enable-foo flags to the cabal configure command line. We could certainly allow and optional description of the flag. Here are some examples: flag: debug default: False synopsis: Whether to turn on debug checks or not. description: Enabling debugging turns on blah blah blah .... flag: gui default: os(windows) || (available(gtk>=0.9.10) && available(cairo>=0.9.10)) As for the meaning, it's not clear to me if it should be that each test is independent of if all constraints must be satisfied on a single package simultaneously. That is if we have a expression like: available ( P > 1) && available ( P < 1) does there have to be a single package P with versions satisfying both constraints (ie impossible) or if the tests are independent and so may be satisfied by there being both P-0.9 and P-1.1 available. I'm not sure it really matters, so we should go for the simple independent test meaning. Opinions? Now for the configurations. The point of view here is that we already know exactly the versions of packages that the builder has chosen for us to use and all we can do is adjust our build settings on that basis or complain that we need more packages to be able to build under these conditions. If we need more packages then the build agent may let us have them or not. (in which case configuration fails). So let's look at a few examples: configuration: flag(debug) cpp-options: -DDEBUG other-modules: Thing.DebugUtils build-depends: SuperDebugLogger >= 1.1 configuration: flag(gui) && os(windows) build-depends: Win32 >= 2.0 configuration: flag(gui) && !os(windows) build-depends: gtk >= 0.9.10, cairo >= 0.9.10 configuration: using(base < 2) build-depends: fps >= 0.8 Note how in the last example, there was no flag involved. This conditional dependency has nothing to do with aspects of the 'outer' environment, it depends only on what packages we've been told to build with. So some fields in the stanza just affect internal aspects of the build like exposing more modules or using some cpp defines or whatever. The more tricky ones are the ones that ask for more deps. There are a few corner cases here. Remember that at the point that we are evaluating the configuration's guard expression have decided on the exact versions of packages that are going to be used. The easy case is adding a new dep, then it's up to the builder (ie Cabal) to figure out if that dep can be satisfied. If it can then the version that Cabal decides on is added to the set of packages we're using and we carry on. If it's not available then the configuration fails. The harder cases are: * adding a build dep on a package that we already depend on, but with a version constraint that is not satisfied by the version that was already selected. * adding a dep which causes the guard of another configuration to change. In the first case I would suggest that this configuration fails. However it may not be total failure, the build agent may re-try the configuration with a different set of package versions (if it has any flexibility in that area - depending on what's available and on any user policy). In the second case I would suggest that we allow configuration guards to change from false to true but not the other way around (ie it would be a configuration failure and an error on the part of the package author). This allows us to do a simple fixpoint and make the result independent of the order of the evaluation of the configuration guards. So the restriction on a guard changing from true to false would ban examples like: configuration: !using(foo) build-depends: foo Since supposing that foo is not in the top level build-depends then ! using(foo) will be true in which case we'll add foo. But now that changes the guard. The alternative to banning this kind of case is to simply ignore any changes from true to false, but then I think we'd get a bit of oddness and the evaluation order would matter in some strange cases. Can anyone think of any sensible examples that this rule would get in the way for? I mentioned earlier that the build agent might need/decide to backtrack if it found that the versions of packages it chose did not satisfy the extra build-deps introduced by some configuration stanza. How about we start with True as the Can anyone see if it's possible to find out a priori if there is a set of packages that can satisfy the conditional constraints. Is this a standard constraint solving problem? Does it have a solution? Here's a nasty example: configuration: using(P = 1.1) build-depends: P = 1.0 configuration: using(P = 1.0) build-depends: P = 1.1 Duncan

5 15

Re: [Haskell] RE: package mounting
by Duncan Coutts 30 Oct '06

30 Oct '06

On Mon, 2006-10-30 at 08:51 +0000, Simon Peyton-Jones wrote: > I think most of you know that GHC 6.6 made (IHMO) a significant step > forward, by allowing a program to contain multiple modules with the same > name, if they are from different packages. That means that package > authors can choose module names freely, rather than worry about > accidentally colliding with other packages. (We'd regard it as > unacceptable if the local variables of a function could not have the > same name as the local variables of another procedure!) > > That still leaves an open question, not resolved by GHC 6.6: what to do > if you want to import module M from two different packages into the same > module? (A related question is when you have to decide what your module > is called.) This can be tackled in at least three different ways, one > being Frederik's proposal. Simon and I are not wedded to any particular > one, and we'd welcome a consensus on what to do. > > The state of play is summarised here > http://hackage.haskell.org/trac/ghc/wiki/GhcPackages > which includes a link to the package-mounting proposal. > > If you care about this stuff, do debate it -- and please record points > that survive a bit of discussion on the Wiki pages. None of this is > very hard to implement; the difficulty is settling on a good design. Fairly closely related to this issue is the question of how Cabal is supposed to deal with building packages that expect multiple versions of a dependent package. Currently this should actually work. If you specify: build-depends: foo = 1.0, foo = 2.0 Then cabal really does pass "-package foo-1.0 -package foo-2.0" to ghc. However it's less clear how we should make it work with configurations where we need to be able to add additional constraints on a package version: build-depends: foo configuration: os(windows) build-depends: foo >= 2.0 So should this mean that we get two versions of package foo? We need to be able to both in fact; add extra versions of a package and add extra version constraints to an existing package. Duncan

1 0