- cabal-devel - Haskell.org

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

[Hackage] #749: Package check cannot handle byte-order-mark in .cabal file
by Hackage 21 Oct '10

21 Oct '10

#749: Package check cannot handle byte-order-mark in .cabal file ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Windows | ----------------------------+----------------------------------------------- When I edit a .cabal file with Notepad (Windows XP) and save it as UTF-8, Notepad writes a byte-order-mark at the start of the file. When testing the package for upload, I got the message: 400 Error in upload line 1: unrecognised field or section: "\65279Name: GeBoP" Henk-Jan van Tuyl -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/749> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Re: [Hackage] #622: wrong HTTP Content-Type for tar.gz files, breaking cabal-install behind some proxies.
by Hackage 20 Oct '10

20 Oct '10

#622: wrong HTTP Content-Type for tar.gz files, breaking cabal-install behind some proxies. ----------------------+----------------------------------------------------- Reporter: guest | Type: enhancement Status: new | Priority: normal Milestone: | Component: cabal-install tool Version: 1.6.0.1 | Severity: normal Keywords: | Difficulty: unknown Ghcversion: | Platform: ----------------------+----------------------------------------------------- Comment(by finlay): Replying to [comment:2 duncan]: In the second case, can cabal-install be more tolerant to broken proxies (#686) and try decompressing, and on failure, check if already has been decompressed ? F -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/622#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal): Make the .cabal file fully 1.10-compliant
by Ian Lynagh 20 Oct '10

20 Oct '10

Wed Oct 20 06:30:37 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Make the .cabal file fully 1.10-compliant Add Default-Language field, and change Extensions to Default-Extensions. M ./Cabal.cabal -1 +3 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

patch applied (cabal): Require "cabal-version: >= 1.10" as we use the new testsuite syntax
by Ian Lynagh 20 Oct '10

20 Oct '10

Wed Oct 20 06:18:29 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Require "cabal-version: >= 1.10" as we use the new testsuite syntax M ./Cabal.cabal -1 +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

patch applied (cabal): Fix warnings: Remove duplicate imports
by Ian Lynagh 20 Oct '10

20 Oct '10

Wed Oct 20 05:57:10 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Fix warnings: Remove duplicate imports M ./Distribution/PackageDescription/PrettyPrint.hs -5 +4 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

patch applied (cabal): Merge conflicts
by Ian Lynagh 20 Oct '10

20 Oct '10

Wed Oct 20 04:22:00 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Merge conflicts M ./Distribution/TestSuite.hs +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

patch applied (cabal): Add final newline
by Ian Lynagh 20 Oct '10

20 Oct '10

Wed Oct 13 05:53:37 PDT 2010 Simon Marlow <marlowsd(a)gmail.com> * Add final newline Something in the Windows build was complaining about the lack of a final newline. M! ./Distribution/TestSuite.hs -1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

patch applied (cabal): Update the pretty printer to the current testsuite interface
by Duncan Coutts 20 Oct '10

20 Oct '10

Wed Oct 20 05:05:06 PDT 2010 Duncan Coutts <duncan(a)haskell.org> * Update the pretty printer to the current testsuite interface M ./Distribution/PackageDescription/PrettyPrint.hs -14 +22 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

patch applied (cabal): Improve error messages about programs not being found
by Duncan Coutts 20 Oct '10

20 Oct '10

Tue Oct 19 00:44:36 PDT 2010 Duncan Coutts <duncan(a)haskell.org> * Improve error messages about programs not being found Make it clear it is a program we are talking about, not a library. M ./Distribution/Simple/Program/Db.hs -4 +7 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0