- cabal-devel - Haskell.org

patch applied (cabal): Fix parsing of empty default-language fields
by Ian Lynagh 27 Oct '10

27 Oct '10

Tue Oct 26 15:03:12 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Fix parsing of empty default-language fields M ./Distribution/PackageDescription/Parse.hs -2 +2 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

patch applied (cabal): Add support for general extension en/disabling
by Ian Lynagh 27 Oct '10

27 Oct '10

Tue Oct 26 07:55:03 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Add support for general extension en/disabling M ./Distribution/PackageDescription/Check.hs -24 +45 M ./Distribution/Simple/GHC.hs -40 +53 M ./Distribution/Simple/Hugs.hs -23 +27 M ./Distribution/Simple/JHC.hs -7 +10 M ./Distribution/Simple/NHC.hs -10 +22 M ./Distribution/Simple/UHC.hs -16 +19 M ./Language/Haskell/Extension.hs -19 +34 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

patch applied (cabal): Tweak a couple of types
by Ian Lynagh 27 Oct '10

27 Oct '10

Tue Oct 26 06:12:50 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Tweak a couple of types M ./Distribution/Simple/Compiler.hs -2 +2 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

patch applied (cabal): Generalise deprecatedExtensions
by Ian Lynagh 27 Oct '10

27 Oct '10

Tue Oct 26 06:11:21 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Generalise deprecatedExtensions It now works with Extensions rather than KnownExtensions M ./Distribution/PackageDescription/Check.hs -1 +1 M ./Language/Haskell/Extension.hs -3 +3 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

patch applied (cabal): Split known-extensions off into their own type, and remove knownExtensions
by Ian Lynagh 27 Oct '10

27 Oct '10

Mon Oct 25 16:26:24 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Split known-extensions off into their own type, and remove knownExtensions The knownExtensions list had already got out of sync with the datatype. Now we use an Enum instance to get the list of constructors. Also, having the actual extensions in a separate type than UnknownExtension and EnableExtension makes it easier to add extension disabling support later. M ./Distribution/PackageDescription/Check.hs -3 +3 M ./Distribution/Simple/GHC.hs -6 +7 M ./Distribution/Simple/Haddock.hs -1 +1 M ./Distribution/Simple/Hugs.hs -6 +7 M ./Distribution/Simple/JHC.hs -3 +4 M ./Distribution/Simple/LHC.hs -3 +3 M ./Distribution/Simple/NHC.hs -3 +4 M ./Distribution/Simple/UHC.hs -2 +3 M ./Language/Haskell/Extension.hs -87 +36 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

darcs patch: Added GZipUtils to handle .tar files wit... (and 1 more)
by Dmitry Astapov 26 Oct '10

26 Oct '10

2 patches for repository http://darcs.haskell.org/cabal-install: Tue Oct 26 23:23:43 EEST 2010 Dmitry Astapov <dastapov(a)gmail.com> * Added GZipUtils to handle .tar files with the same code as .tar.gz Wed Oct 27 00:26:06 EEST 2010 Dmitry Astapov <dastapov(a)gmail.com> * Use "maybeDecompress" to handle broken proxies that transparenty decompress network streams. Closes #622, #686. Cabal update could fail in some cases, see http://trac.haskell.org/http/ticket/109283

1 0

darcs patch: Split known-extensions off into their ow... (and 3 more)
by Ian Lynagh 26 Oct '10

26 Oct '10

4 patches for repository http://darcs.haskell.org/packages/Cabal: Tue Oct 26 00:26:24 BST 2010 Ian Lynagh <igloo(a)earth.li> * Split known-extensions off into their own type, and remove knownExtensions The knownExtensions list had already got out of sync with the datatype. Now we use an Enum instance to get the list of constructors. Also, having the actual extensions in a separate type than UnknownExtension and EnableExtension makes it easier to add extension disabling support later. Tue Oct 26 14:11:21 BST 2010 Ian Lynagh <igloo(a)earth.li> * Generalise deprecatedExtensions It now works with Extensions rather than KnownExtensions Tue Oct 26 14:12:50 BST 2010 Ian Lynagh <igloo(a)earth.li> * Tweak a couple of types Tue Oct 26 15:55:03 BST 2010 Ian Lynagh <igloo(a)earth.li> * Add support for general extension en/disabling

1 0

darcs patch: Split known-extensions off into their own type, and re...
by Ian Lynagh 26 Oct '10

26 Oct '10

1 patch for repository http://darcs.haskell.org/packages/Cabal: Tue Oct 26 00:26:24 BST 2010 Ian Lynagh <igloo(a)earth.li> * Split known-extensions off into their own type, and remove knownExtensions The knownExtensions list had already got out of sync with the datatype. Now we use an Enum instance to get the list of constructors. Also, having the actual extensions in a separate type than UnknownExtension and EnableExtension makes it easier to add extension disabling support later.

1 0

patch applied (cabal): Add a test program to look for ghc extensions that are not registered
by Duncan Coutts 25 Oct '10

25 Oct '10

Mon Oct 25 09:35:36 PDT 2010 Duncan Coutts <duncan(a)haskell.org> * Add a test program to look for ghc extensions that are not registered Should live in the ghc testsuite but no harm having it here too. A ./tests/misc/ A ./tests/misc/ghc-supported-languages.hs View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

Re: cabal, UHC, and different backends
by Duncan Coutts 21 Oct '10

21 Oct '10

Hi Atze, btw, I'm cc-ing the cabal-devel list since this is relevant for the Cabal specification, and other people may like to chime in on the issue. On Tue, 2010-10-19 at 10:13 +0200, Atze Dijkstra wrote: > On 18 Oct, 2010, at 23:38 , Duncan Coutts wrote: > > > > > So the approach I would like to take is to have a proper notion of > > "way". This term comes from GHC where profiling, normal, etc are all > > different "ways". NHC had several different profiling ways. I think the > > notion can be generalised and supported in Cabal. It should cover both > > things like the same backend but ABI-incompatible options (like > > profiling) and also entirely different backends. Cabal would want to > > track each package separately for each way. It would need to know which > > ways are compatible/incompatible so it knows if it can mix packages of > > different ways (backend obviously cannot, but some forms of profiling or > > parallel vectorisation are ABI compatible and are expected to be mixed). > > > > So yes we have a notion of "the right thing to do" but there's no > > current code in Cabal for doing this. Simon has also recently been > > interested in the issue of tracking profiled libs separately from > > normal. So perhaps we can cooperate on a detailed design. > > I intend to be at BelHac, we can then spend some time on it. However > for kicking off immediately: > - There are (at least) 2 dimensions in which a compiler must be able > to vary: target + variation, so I guess that makes type Way = > (Target,Variation). Possibly a third: Platform, when cross compilation > would come into play (like jhc does). The way I'd like to handle this at the level of the Cabal spec (which is supposed to be mostly compiler-agnostic) is to say that the way field in the installed package info is just a string. This is the same as the new installedPackageID field which is also a string (and distinct from the source package id). This allows different compilers to encode different information. For example for hugs and nhc the installedPackageID is a string containing the name and source version, but for ghc it also contains an ABI hash. For the way, we can do something similar. UHC can encode its target, variation etc and other compilers can do different things. The main point is to distinguish different ways. Then interpreting which ways are compatible is compiler-dependent. > - UHC currently organises its internal directory structure like > <pkg>/<compiler-variant>/<target>/<variation>, of which > <compiler-variant> is UHC specific, but something like this is needed > to distinguish. This is something we could standardize on, that is, > cabal assumes a fixed way of mapping Way to FilePath. Right, I suspect the standard layout will still be compiler-dependent but for several compilers it may include the way. > - An issue is whether a compiler knows of such a convention, or not? > UHC currently knows for which target + variation it is compiling and > adapts its location for generating package content. This could be > factored out, or not. I am not sure what is best, although factoring > out would make a compiler rely more on cabal, make compiler and cabal > more intertwined. However, my guess is, that this part has the > greatest impact on cabal. Ideally, I would like the compilers to have no hard coded knowledge of the layout convention. Instead the compilers should just use the installed package info. This is what GHC does for example. In future I would like to modify the default layout that cabal-install uses for installed packages to use a Nix-style persistent package store. Also, distributions and other custom deployments typically want more control over the layout. Of course people doing this have to be aware of the constraints. > - As 1 end of this design space, when a compiler knows about these > locations, changes to cabal can mostly be avoided. For UHC I ran cabal > with a --uhc-option=-tjscript for specifying a different target, and > all went well apart from the generation of a package descriptor file. So, since the job of a package manager does involve knowing a fair bit about the layout and organisation of installed packages, I would like to see cabal know something about the "way", just so that it can allow multiple instances of the same package with different ways. The package registration info would also contain the way. In any case, cabal needs to know the way to work out which dependencies can correctly be combined together. > If this would also be done by UHC, cabal's only job (??) would be to > pass the appropriate flags around and allow a .cabal file have > constraints on target etc. > - .cabal files need a way to refer to targets etc for constraints > (i.e., package only compiles for certain backend). Hmm. I'll think about that. Can it perhaps be expressed as a language restriction? > - Should targets and variations be standardized upon, i.e. data Target > = ...? Or just allow any String to act as a Target, i.e. type Target = > String? As I mentioned above, the information in the way will be different for different compilers, so I think string is appropriate. Duncan

2 1