April 2008 - cabal-devel

Re: nice little Cabal gotcha
by Duncan Coutts 20 Apr '08

20 Apr '08

On Thu, 2008-04-10 at 11:29 +0700, Peter Gammie wrote: > On 10/04/2008, at 3:57 AM, Duncan Coutts wrote: > > On Mon, 2008-04-07 at 18:37 +0700, Peter Gammie wrote: > >> Imagine this: you're hacking a library, and occasionally you put a "- > >> p" on your config line and sometimes you don't. > > > > Yep. And Cabal doesn't track if the profiling versions of dependencies > > are installed. > > > >> (My cycle is occasional-clean-setup then build, which I grant might > >> be > >> a bit paranoid. I get impatient and fiddle with the profiling and > >> optimisation options.) > >> > >> Now, if one compiles a library with "-p", then without it, the old > >> profiling library persists in the installed location, leading to some > >> head scratching when a later compilation with a "-p" config option > >> mysteriously fails. > > > > You mean because the old version of the profiling lib is installed but > > it does not match the newer non-profiling version? So building a > > dependent lib with -p fails with weird complication errors? > > Just to clarify slightly: "install" is just additive, so any old cruft > in the install directories persists if not overwritten. If the package > interface hasn't changed, the later "-p" compilation of something else > may succeed, but misbehave relative to expectations. Ah, so same interface but changed semantics. > My proposal is that if cabal is going to install something in, e.g.: > > ~/lib/package/ghc-6.6.1/ > > that it say: > > rm -rf ~/lib/package/ghc-6.6.1/* > > first. Surely it is reasonable to say Cabal "owns" that particular > directory? I don't think so, no. > I also feel the same way about documentation. > > Now tracking dependencies a partial solution to this: imagine I remove > a module from my .cabal file, then "clean" "build" "install". Will > Cabal delete the removed-module's .hi (etc.) file? No. > Can you expand on your squeamishness? We should not delete files we don't know that we own. We only know we own files we're installing. So we cannot delete anything. Only a package manager can do that because it knows what files belong to the package we're replacing. Of course cabal-install is a package manager of sorts so if it tracked what files belonged to packages it installed then it'd know what files to remove when it replaced packages. > I can feel a proposal for a "--force" relative coming on, something > like "--purge-old-crap". :-) The other problem is that we do not necessarily install all files into one directory. In fact it's not even the default on unix. The various different kinds of files go in different dirs and the user can change any of them. > I'll write up a ticket after your response. Perhaps I can convince you that the better solution is to get Cabal to provide a way track installed files and for cabal-install to actually do so. Duncan

2 2

Re: [Haskell-cafe] announcing franchise 0.0
by Duncan Coutts 18 Apr '08

18 Apr '08

In message <20080418153703.GN8763(a)darcs.net> haskell-cafe(a)haskell.org, darcs-devel(a)darcs.net writes: > One goal of franchise is to not require developers to provide redundant > information. For instance, you've already listed all the modules you use, > and ghc already knows which modules are present in which packages, so > there's in general no need for you to list the packages that you require, > much less their versions. Yeah, this is an important point. Part of the original idea of Cabal was to help distribution by properly tracking dependencies. It's not too bad for that use case but it's really a pain in comparison to ghc --make or hmake which just do the right thing given the environment. Part of our plan for Cabal 2.x is to do proper module dependency chasing so that it will work without a .cabal file in simple cases and be usable for the ghc --make or hmake use cases (but with support for preprocessors and parallel build). It should be possible to just start hacking and derive a skeleton .cabal file afterwards if you decide you want to distribute a package. Duncan

1 0

Cabal bugs/oddities
by Neil Mitchell 14 Apr '08

14 Apr '08

Hi, All these bugs are against the homeomorphic library I have written. To play along, you can do darcs get --partial http://www.cs.york.ac.uk/fp/darcs/homeomorphic Bug 1: cabal install worked the first time, running it a second time fails. $ cabal install .. works.. $ cabal install .. configuring ... setupWrapper in Nothing : ["build"] Preprocessing library homeomorphic-0.1... Building homeomorphic-0.1... E:\ghc\ghc-6.8.2\bin\ar.exe: creating dist\build\libHShomeomorphic-0.1.a setupWrapper in Nothing : ["install"] cabal: Error: some packages failed to install: homeomorphic-0.1 failed during the final install step. Bug 2: cabal haddock fails $ cabal haddock Preprocessing library homeomorphic-0.1... Running Haddock for homeomorphic-0.1... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: base-3.0.1.0, QuickCheck-1.1.0.0, mtl-1.1.0.0, containers-0.1.0.1 dist/build/tmp/Data/Homeomorphic/Hash1.hs:4:0: Include/Hash.hs: No such file or directory This one may well be my fault, if some extra magic is required for the haddock with CPP, but not the building - but that seems weird, if there is enough info to build the file, surely there is enough info to haddock it Bug 3: Cabal upload doesn't work: $ cabal upload Username: ... Password: .... Not even a "goodbye and thanks for your password, I'm off to raid your paypal". It should certainly say something $ cabal upload dist E:\Neil\homeomorphic>cabal upload dist\homeomorphic-0.1.tar.gz Hackage username: NeilMitchell Hackage password: yoda Uploading dist\homeomorphic-0.1.tar.gz... ERROR: dist\homeomorphic-0.1.tar.gz: 400 Error in upload 400 error in upload - not the worlds most helpful error message... Bug 4: Cabal upload asks for your password in plain text. That one is security related - you are asking for someones password, and giving the appearance that you aren't overly fussed about keeping it secret. Thanks Neil

2 4

[Fwd: darcs patch: Made it possible to run executeables with data files i...]
by Duncan Coutts 13 Apr '08

13 Apr '08

Comments? Perhaps we want to generalise this for the other dirs too, prefix, libdir etc to provide a way to have relocatable packages on unix with a wrapper script. Also, comments on the name of the environment variables would be appreciated and indeed if people agree that using env vars is the right approach. Duncan

1 0

darcs patch: Change dependency resolution algorithm. (and 4 more)
by Thomas Schilling 13 Apr '08

13 Apr '08

Sun Apr 13 15:18:07 CEST 2008 Thomas Schilling <nominolo(a)gmail.com> * Change dependency resolution algorithm. There were two reasons to do this. Firstly, this formulation makes it easier to add the --constraint command line flag that adds additional constraints on the packages that should be used. Secondly, with the orgininal algorithm it was possible to satisfy the constraint "foo < 1, foo > 2" if we had two versions of package "foo" which each satisfy one constraint. This patch fixes this by requiring the same package to satisfy both constraints (which of course is impossible in this case). Sun Apr 13 15:18:39 CEST 2008 Thomas Schilling <nominolo(a)gmail.com> * Fix/Add documentation. Sun Apr 13 15:20:02 CEST 2008 Thomas Schilling <nominolo(a)gmail.com> * Add simple test case for the dependency resolution case. This should go into the test suite one day. Sun Apr 13 20:20:42 CEST 2008 Thomas Schilling <nominolo(a)gmail.com> * Add 'readP_to_E' function that takes the longest parse. Sun Apr 13 20:26:59 CEST 2008 Thomas Schilling <nominolo(a)gmail.com> * Fix #224. We do not yet warn if the user specified a dependency that did not occur in the package (it is just silently ignored.)

1 0

darcs patch: Change dependency resolution algorithm. (and 2 more)
by Thomas Schilling 13 Apr '08

13 Apr '08

Sun Apr 13 15:18:07 CEST 2008 Thomas Schilling <nominolo(a)gmail.com> * Change dependency resolution algorithm. There were two reasons to do this. Firstly, this formulation makes it easier to add the --constraint command line flag that adds additional constraints on the packages that should be used. Secondly, with the orgininal algorithm it was possible to satisfy the constraint "foo < 1, foo > 2" if we had two versions of package "foo" which each satisfy one constraint. This patch fixes this by requiring the same package to satisfy both constraints (which of course is impossible in this case). Sun Apr 13 15:18:39 CEST 2008 Thomas Schilling <nominolo(a)gmail.com> * Fix/Add documentation. Sun Apr 13 15:20:02 CEST 2008 Thomas Schilling <nominolo(a)gmail.com> * Add simple test case for the dependency resolution case. This should go into the test suite one day.

1 0

patch applied (cabal-branches/cabal-1.4): fix for #187 -- directory of Paths_packagename is included when looking for source files
by Duncan Coutts 12 Apr '08

12 Apr '08

Sat Apr 12 13:49:04 PDT 2008 Andres Loeh <mail(a)andres-loeh.de> * fix for #187 -- directory of Paths_packagename is included when looking for source files M ./Distribution/Simple/GHC.hs -1 +1 M ./Distribution/Simple/Haddock.hs -1 +1 M ./Distribution/Simple/JHC.hs -1 +1 M ./Distribution/Simple/PreProcess.hs -2 +3 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008041220…

1 0

patch applied (cabal): fix for #187 -- directory of Paths_packagename is included when looking for source files
by Duncan Coutts 12 Apr '08

12 Apr '08

Sat Apr 12 13:49:04 PDT 2008 Andres Loeh <mail(a)andres-loeh.de> * fix for #187 -- directory of Paths_packagename is included when looking for source files M ./Distribution/Simple/GHC.hs -1 +1 M ./Distribution/Simple/Haddock.hs -1 +1 M ./Distribution/Simple/JHC.hs -1 +1 M ./Distribution/Simple/PreProcess.hs -2 +3 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080412204904-90534-67d6c3ff…

1 0

patch applied (cabal-branches/cabal-1.4): Check for the required cabal version early in parsing
by Duncan Coutts 11 Apr '08

11 Apr '08

Wed Apr 9 08:46:55 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Check for the required cabal version early in parsing Previously we only checked the "cabal-version" field after parsing and all other configure processing. If the package really needs a later Cabal version it is of course highly likely that parsing or configure are going to fail and the user is not going to get the helpful error message about the version of Cabal required. So now we do the check early during parsing. If a later version is required and parsing subsequently fails, we now report the version issue, not the subsequent parse error. If parsing succeeds we still issue a warning which should be a useful hint to the user if subsequent configure processing fails. M ./Distribution/PackageDescription/Parse.hs -15 +34 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008040915…

1 0

patch applied (cabal-branches/cabal-1.4): Use relative file paths in .cabal parse error messages
by Duncan Coutts 11 Apr '08

11 Apr '08

Wed Apr 9 08:40:30 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Use relative file paths in .cabal parse error messages Do this by normalising the file path in the error message and when looking for .cabal files, by looking in '.' rather than the absolute path of the current directory. M ./Distribution/Simple/Utils.hs -6 +8 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008040915…

1 0