Re: Linker change in GHC 7.8 leads to widespread issues

On 02/12/2014 21:43, Miëtek Bak wrote: On 2014-12-02, at 21:31, Carter Schonwald wrote: whats an example of such a package? text-icu. https://github.com/bos/text-icu/pull/9 FWIW, I’m in favour of fixing this at the Cabal level. https://github.com/haskell/cabal/issues/2207 I'm actually ra

Re: Advance notice that I'd like to make Cabal depend on parsec

On 18 March 2013 03:08, Simon Peyton-Jones wrote: > Is it essential, or even sensical, that the serialization format GHC needs > for storing package info bear any relation to the human authored form? If > not, the split out of the package types could be accomplished in a way where > GHC uses simpl

Re: Cabal and GHC

On 22/11/2012 19:54, Gábor Lehel wrote: On Thu, Nov 22, 2012 at 8:41 PM, Henning Thielemann wrote: On Thu, 22 Nov 2012, Brandon Allbery wrote: I am wondering if we're trying to solve the problem in the wrong way. The core of the problem is that various things get baked into libraries in the

Re: Cabal and GHC

On 22/11/2012 11:00, Duncan Coutts wrote: he nix-style approach that we've been advocating for years comes in. That's what Philipp Schuster's GSoC this summer was all about. That's aiming to do exactly what Simon is talking about here. It's about allowing sets of packages to be installed simultan

Re: deprecating

On 22/10/2012 19:15, Ashley Yakeley wrote: On 22.10.2012 11:05, Johan Tibell wrote: I think it's OK if a compiler accepts a program incorrectly marked "Rank2Types" when it actually requires rank-n types? It's an interesting question: does Rank2Types mean "I require at least rank-2 types" or "

Re: deprecating

On 23/10/2012 09:04, Roman Leshchinskiy wrote: Bryan O'Sullivan wrote: On Mon, Oct 22, 2012 at 4:14 PM, Simon Peyton-Jones wrote: Do you mean “silently and forever�? I think that's what I mean, yes. As Johan notes, many of us run our continuous builds of our packages with -Wall -Werro

Re: Gearing up for a cabal-install-1.16.0 release

On 01/10/2012 09:26, Duncan Coutts wrote: On 1 October 2012 04:21, Johan Tibell wrote: Hi, I don't want to hold up the release on this issue if it needs more discussion. I'd like to make another Cabal/cabal-install release before end of the year (probably around GHC's release timeline), to inc

Re: [Hackage] #791: Large libraries not installable on OS X

Hi Conal, The Hackage bug you quoted is related to this GHC ticket: http://hackage.haskell.org/trac/ghc/ticket/4326 the root cause is a size limitation in the OS X linker triggered when libraries get particularly large. We worked around it (actually Ian did) in GHC by adding support to the G

patch applied (cabal): update for containers-0.4

Fri Sep 3 03:51:47 PDT 2010 Simon Marlow * update for containers-0.4 M ./Cabal.cabal -1 +1 M ./Distribution/PackageDescription/Configuration.hs -1 +2 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=20100903105147-12142

Re: Major installation failure and impossible to post to cabal-devel

On 21/05/2010 03:08, Mats Ahlgren wrote: Additionally, a friend was kind enough to point out: "(To avoid spam we ask you to login with username guest and password haskell' - note the apostrophe on the end.)" -- from http://www.haskell.org/cabal/ This is mentioned on an entire-separate-website th

Re: Major installation failure and impossible to post to cabal-devel

On 21/05/2010 03:00, Mats Ahlgren wrote: Hello, It took me about 3 hours and 7 attempts to post to this list, or any similar mailing list. It seems after much sleuthing that my registration did not go through (despite clicking on the confirmation button on the confirmation link page), and the er

Re: cabal-install-0.8 final testing

On 20/12/2009 01:46, Duncan Coutts wrote: On Fri, 2009-12-18 at 19:44 -0800, Dave Bayer wrote: Hi Duncan, Installation was easy (I typed "cabal-install HTTP zlib cabal-install" ;-). Thanks for testing it. I've uploaded it to hackage. Overall, seems to work fine. I couldn't build darcs, but

patch applied (cabal): Loosen the invariant, it was too strict

Tue Oct 6 06:37:56 PDT 2009 Simon Marlow * Loosen the invariant, it was too strict Ignore-this: 6087cfc11c19d4bac2fddcf007e9bb7c The packages do not need to be in the same order when sorted by package name as when sorted by InstalledPackageId. M ./Distribution/Simple

Re: Windows Install Issues for erf (and statistics)

On 23/09/2009 09:03, Simon Marlow wrote: On 22/09/2009 17:37, Lennart Augustsson wrote: I'll look into it at work tomorrow. The problem I had before was that it worked in ghc, but not ghci. If there's no bug report I'll file one. I wouldn't say it was a bug - the function

Re: Windows Install Issues for erf (and statistics)

On 23/09/2009 10:35, dominic.stein...@barclayscapital.com wrote: -Original Message- From: Simon Marlow [mailto:marlo...@gmail.com] Sent: 22 September 2009 13:44 To: Dominic Steinitz Cc: Lennart Augustsson; Steinitz, Dominic: Markets (LDN); cabal-devel@haskell.org; librar

Re: Windows Install Issues for erf (and statistics)

Wed, Sep 23, 2009 at 12:17 AM, Bryan O'Sullivan wrote: On Tue, Sep 22, 2009 at 5:43 AM, Simon Marlow wrote: Are you sure the problem you had isn't just that the C erfc function is not available on Windows? I looked for it, and I can't find any documentation on MSDN, outside

Re: Windows Install Issues for erf (and statistics)

On 21/09/2009 22:14, Dominic Steinitz wrote: Simon Marlow wrote: I couldn't find anything - happy to look into it if someone points me to the ticket. I think this is it: http://hackage.haskell.org/trac/ghc/ticket/3513 The problem there seems to be that the network library is ca

Re: Windows Install Issues for erf (and statistics)

I couldn't find anything - happy to look into it if someone points me to the ticket. Cheers, Simon On 20/09/2009 12:22, Lennart Augustsson wrote: I complained about the very same thing, I think there's even a ghc bug report about it. It's something about how symbols are looked up and l

patch applied (cabal): Use -package-id rather than -package with GHC 6.11+

Sun Sep 6 04:24:16 PDT 2009 Simon Marlow * Use -package-id rather than -package with GHC 6.11+ Ignore-this: a9cb1e8684411ea3fa04e0d54826f76b M ./Distribution/Simple/GHC.hs -3 +12 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090906112416-12142

patch applied (cabal): Add the ABI hash to the InstalledPackageId for inplace registrations too

Wed Aug 26 08:51:57 PDT 2009 Simon Marlow * Add the ABI hash to the InstalledPackageId for inplace registrations too Ignore-this: f10a1e90492a356a8ed8ed78fd056176 Previously, we just added a -inplace suffix, but this will cause problems when developing multiple packages inplace, and then

Re: Changelogs and "available since"

On 17/08/2009 17:18, Laszlo Nagy wrote: Hi All, I was volunteer to solve this problem: In a conversation on the librar...@haskell.org I was suggested to scratch my idea here. I would use hoogle for this. Currently it stores the pa

patch applied (cabal): Help Cabal find gcc/ld on Windows

Fri Jun 26 07:02:50 PDT 2009 Simon Marlow * Help Cabal find gcc/ld on Windows Ignore-this: bad21fe3047bc6e23165160c88dd53d9 the layout changed in the new GHC build system M ./Distribution/Simple/GHC.hs -8 +18 View patch online: http://darcs.haskell.org/cabal/_darcs/patches

patch applied (cabal): clean up createTempDirectory, using System.Posix or System.Directory

Thu Jun 25 03:56:48 PDT 2009 Simon Marlow * clean up createTempDirectory, using System.Posix or System.Directory Ignore-this: 732aac57116c308198a8aaa2f67ec475 rather than low-level System.Posix.Internals operations which are about to go away. M ./Cabal.cabal +3 M ./Distribution

patch applied (cabal): follow change in System.Posix.Internals.c_open

Mon Jun 22 06:36:54 PDT 2009 Simon Marlow * follow change in System.Posix.Internals.c_open Ignore-this: d2c775473d6dfb1dcca40f51834a2d26 M ./Distribution/Compat/TempFile.hs -1 +8 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090622133654-12142

patch applied (cabal): update to work with the new GHC IO library internals (fdToHandle)

Fri Jun 12 02:53:46 PDT 2009 Simon Marlow * update to work with the new GHC IO library internals (fdToHandle) Ignore-this: 2697bd2b64b3231ab4d9bb13490c124f M ./Distribution/Compat/TempFile.hs +4 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090612095346-12142

Re: cabal

Claus Reinke wrote: The basic problem here is that the version number of the network package has not been bumped. .. .. Of course that's not true here because the package has changed without the version being bumped. .. Indeed the only reason it's trying to rebuild it at all is because the instal

patch applied (cabal): add missing exeExtension when stripping an executable

Tue Oct 7 06:47:57 PDT 2008 Simon Marlow <[EMAIL PROTECTED]> * add missing exeExtension when stripping an executable M ./Distribution/Simple/GHC.hs -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20081007134757-12142-8f1e6cc41a58d17ecd0d1c1469a62ec9837b9

patch applied (cabal): Haddock 2: #include

Mon Sep 1 07:58:43 PDT 2008 Simon Marlow <[EMAIL PROTECTED]> * Haddock 2: #include M ./Distribution/Simple/Haddock.hs -1 +3 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080901145843-12142-a83ddca049f020bf99347c9dbb902c24d3f75

patch applied (cabal): Don't pass cc-options to Haskell compilations

Thu Aug 21 06:34:21 PDT 2008 Simon Marlow <[EMAIL PROTECTED]> * Don't pass cc-options to Haskell compilations This has no effect with GHC 6.9, and with earlier GHC's it was a misuse of cc-options. M ./Distribution/Simple/GHC.hs -1 View patch online: http://darcs.h

patch applied (cabal): Don't propagate cc-options to the InstalledPackageInfo

Thu Aug 21 06:25:51 PDT 2008 Simon Marlow <[EMAIL PROTECTED]> * Don't propagate cc-options to the InstalledPackageInfo cc-options is for options to be passed to C compilations in the current package. If we propagate those options to the InstalledPackageInfo, they get

patch applied (cabal): Add auto-generated CPP macros for package version testing

Mon Aug 11 10:30:16 PDT 2008 Simon Marlow <[EMAIL PROTECTED]> * Add auto-generated CPP macros for package version testing Now when using CPP you get MIN_VERSION_(A,B,C) for each in build-depends, which is true if the version of in use is >= A.B.C, using t

patch applied (cabal): allow Cabal to use base-4

Wed Aug 6 06:05:12 PDT 2008 Simon Marlow <[EMAIL PROTECTED]> * allow Cabal to use base-4 M ./Cabal.cabal -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080806130512-12142-d7e77cfa0c5727751a7ba1dac21c0eaaf1226

patch applied (cabal): Windows fixes

Sun Aug 3 13:12:53 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]> * Windows fixes M ./Distribution/Compat/Exception.hs -8 +17 M ./Distribution/Simple/Utils.hs -3 +6 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080803201253-3fd76-74cf4411dd1b7c4e2c270465664da76db1c2f4c2.

patch applied (cabal): setup makefile: put the source-dir suffix rules after the distdir suffix rules

Wed Aug 6 06:03:09 PDT 2008 Simon Marlow <[EMAIL PROTECTED]> * setup makefile: put the source-dir suffix rules after the distdir suffix rules This matches the behaviour of 'setup build' works, and is robust to people accidentally having old preprocessed sources lyi

Re: Specifying dependencies on Haskell code

Roman Leshchinskiy wrote: IMO, a package is absolutely the wrong thing to depend on. Essentially, a package is an implementation of an interface and depending on implementations is a bad thing. Code should only depend on interfaces which are completely independent entities. I suspect that a lo

Re: suggestion: add a .ehs file type

ndex of the user's guide so should probably be turned off. I have no idea what it does. Note, in all cases where the extension is turned on by default, there should be a language pragma to turn it off. -Alex- Simon Marlow wrote: Alex Jacobson wrote: Simon, from what I can tell, wi

Re: suggestion: add a .ehs file type

t parses a strict superset of Haskell98 - and that's hard to achieve. Cheers, Simon I am not taking a position here on the merits of any extensions. -Alex- Simon Marlow wrote: Alex Jacobson wrote: Extensions that change syntax are effectively declared by the use of that syn

Re: suggestion: add a .ehs file type

Alex Jacobson wrote: Extensions that change syntax are effectively declared by the use of that syntax. If you can parse the source, then you know which extensions it uses. I thought we'd already established that this isn't possible. Here are some code fragments that parse differently depen

Re: [Haskell] Re: Trying to install binary-0.4

Ross Paterson wrote: On Wed, Oct 17, 2007 at 12:54:12PM +0100, Simon Marlow wrote: I've written down the proposed policy for versioning here: http://haskell.org/haskellwiki/Package_versioning_policy It turned out there was a previous page written by Bulat that contained essentially

Re: [Haskell] Re: Trying to install binary-0.4

I've written down the proposed policy for versioning here: http://haskell.org/haskellwiki/Package_versioning_policy It turned out there was a previous page written by Bulat that contained essentially this policy, but it wasn't linked from anywhere which explains why it was overlooked. I too

Re: [Haskell] Re: Trying to install binary-0.4

Neil Mitchell wrote: Hi I agree. >= 1.0 isn't viable in the long term. Rather, a specific list, or bounded range of tested versions seems likely to be more robust. In general, if it compiles and type checks, it will work. It is rare that an interface stays sufficiently similar that the thing

Re: [Haskell-cafe] Re: Proposal: register a package as providingseveral API versions

Claus Reinke wrote: It could be done using the tricks that Claus just posted and I followed up on. You'd need a separate package for hsFoo-2 that specifies exactly which bits of hsFoo-3 are re-exported. Given some Cabal support and a little extension in GHC, this could be made relatively pa

Re: Proposal: register a package as providing several API versions

ChrisK wrote: Simon Marlow wrote: Several good points have been raised in this thread, and while I might not agree with everything, I think we can all agree on the goal: things shouldn't break so often. I have another concrete proposal to avoid things breaking so often. Let us steal

Re: [Haskell] Re: Trying to install binary-0.4

Simon Marlow wrote: Claus Reinke wrote: - if you provide a 'base' configuration that pulls in the stuff that used to be in base, the package will work I don't know of a way to do that. The name of the package is baked into the object files at compile time, so you can

Re: [Haskell] Re: Trying to install binary-0.4

Claus Reinke wrote: - if you provide a 'base' configuration that pulls in the stuff that used to be in base, the package will work I don't know of a way to do that. The name of the package is baked into the object files at compile time, so you can't use the same compiled module in more tha

Re: [Haskell] Re: Trying to install binary-0.4

Several good points have been raised in this thread, and while I might not agree with everything, I think we can all agree on the goal: things shouldn't break so often. So rather than keep replying to individual points, I'd like to make some concrete proposals so we can make progress. 1. Doc

Re: Todays breakage

Ian Lynagh wrote: On Wed, Aug 08, 2007 at 10:27:07AM +1000, Manuel M T Chakravarty wrote: /opt/local/bin/ghc -H64m -Onot -fasm -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/

Re: Broken head

Ian Lynagh wrote: On Wed, Aug 08, 2007 at 04:19:29PM +0100, Simon Marlow wrote: I've just made GHC's Cabal into a branch. FWIW I think this is a mistake. It'll make changing Cabal as part of changes to the larger system harder, and increases the global amount of effort nece

Re: Broken head

Manuel M T Chakravarty wrote: An automated system would be cool, but it'd require some effort to set up. In the meantime, we should probably go with SimonM's proposal and just make GHC use a subset-branch of the main Cabal repo. Pulling changes over into GHC's Cabal branch would be a manual

Re: reason for both --libdir and --libsubdir ?

Duncan Coutts wrote: I am trying to understand the reason we have so many --dir flags to configure. I'd prefer to remove what appear to be duplicates and add some more dir overrides for specific file types (like docs). We currently have: --libdir= and --libsubdir= --datadir= and --datasubdir=

Re: Developing cabal2wix - building Windows installers automatically

Esa Ilari Vuokko wrote: Hi, I decided to try to build a cabal -> wix converter, cabal2wix, to make it easier to generate Windows installers for cabal-packages. My main target is ghc-compiled libraries. There are few issues I've ran into and I'd appreciate any comments on them. I'll try to pub

Re: hacking cabal is too hard...

Duncan Coutts wrote: so what can we do about it? BTW, thanks for all the cleanup you did over the weekend, looks great. Some barriers to entry: 1. reporting bugs requires logging in, many people still miss this. 2. bug reports get ignored (which is disheartening to users)

Re: Broken head

Manuel M T Chakravarty wrote: Running validate on the current (Mon Aug 6 12:42:45 EST 2007) head, gives me /opt/local/bin/ghc -H64m -Onot -fasm -I. -Iinclude -Rghc-timing -O -fasm -ignore-package Cabal -ignore-package filepath -I../libraries -fglasgow-exts -no-recomp-c Distribution/Syst

Re: Cabal Configurations Status Report

Thomas Schilling wrote: Hello cabal-devel, the following is a summary of the changes to Cabal to enable Cabal Configurations. As we are about to integrate Cabal configurations into the main branch in order to get more testing feedback, I think it is a good time to give an overview about

Re: new target ./setup plain_source?

Ian Lynagh wrote: Hi Marc, On Sat, Jul 21, 2007 at 02:26:47AM +0200, Marc Weber wrote: What about adding another target ./setup plain_source which should preprocess everything (including cpp) and output the files to an extra directory? Why? This could be used for haddock documentation generatio

Re: Windows line endings in .cabal file goes wrong

Neil Mitchell wrote: When installing a .cabal package which has Windows line endings, the executable name is read as file^M. There are a few possible solutions: 1) Ban \r from .cabal files - cabal-upload should check this if this choice is made. 2) Cope with \r, a simple filter (/= '\r') shoul

Re: Converting Yhc to use Cabal

Ian Lynagh wrote: Can it do things like testing the size of int/long etc? No. But of course the advantage of Setup.hs is that you can write code to do anything you like in there, including tests for the size of int/long. Cheers, Simon __

Re: Test Cases for Configurations

Ian Lynagh wrote: On Mon, Jun 18, 2007 at 09:16:10AM +0100, Simon Marlow wrote: modules: ... modules[testing]: ... modules[internal]: ... A simpler way to solve this problem is to have two packages, with the first package (foo-internal) exporting all the modules, and the second (foo

Re: Test Cases for Configurations

Ian Lynagh wrote: On Fri, Jun 15, 2007 at 03:06:07PM +0200, Thomas Schilling wrote: On 15 jun 2007, at 14.09, Neil Mitchell wrote: this being common practice, and yet permit it occasionally. One thing I would like is given a package _data, which provides a data type, and a package _class whic

Re: Test Cases for Configurations

Thomas Schilling wrote: it's still a little work to do, but I think I'll be able to try and use Cabal configurations some time next week. Do you guys have any ideas what we could use as a good test case? The goal is to find out how well the current scheme applies to actual use cases (and if

Re: Parsec as a Dependency?

Thomas Schilling wrote: Hi Caballers, now that .cabal files are getting a more complex syntax (due to configurations), I'd really like to use Parsec instead of lots of hand-written and hard to maintain parsing code. By getting rid of ReadP-based field parsing, we'd also get proper error message

Re: Cabal -extra-lib-dirs and -rpath, also framework-dirs

Duncan Coutts wrote: 2. Cabal doesn't recognise "framework-dirs" as a field name, even though it shows up in "ghc-pkg describe". Yes, cabal does not currently support that field. It probably should. The format used by ghc-pkg is quite similar to the cabal format, but not exactly the same, so d

Re: Trac should send bug updates to this list?

Isaac Jones wrote: Simon Marlow wrote: We were musing on #ghc today about how visible (or not) the Cabal Trac is. I personally visit it very rarely. It would probably help if Trac sent bug updates to this list. Igloo had a recollection that Isaac didn't like the idea - Isaac, any com

Trac should send bug updates to this list?

We were musing on #ghc today about how visible (or not) the Cabal Trac is. I personally visit it very rarely. It would probably help if Trac sent bug updates to this list. Igloo had a recollection that Isaac didn't like the idea - Isaac, any comments? We could create a separate list if nece

Re: patch applied (cabal-install): Use user installs by default

Ian Lynagh wrote: On Thu, May 10, 2007 at 09:25:41AM +0100, Simon Marlow wrote: $ cabal-install foo You don't have permission to install packages globally (for all users). Either: run cabal-install as root, or add the --user flag to install packages for the current user only.

Re: patch applied (cabal-install): Use user installs by default

Duncan Coutts wrote: On Mon, 2007-05-07 at 09:20 +0100, Simon Marlow wrote: Duncan Coutts wrote: Fri May 4 03:46:52 PDT 2007 Duncan Coutts <[EMAIL PROTECTED]> * Use user installs by default So it "Just Works"tm without needing extra options or sudo fiddling. If you ca

Re: Cleaning up hooks

Ian Lynagh wrote: On Tue, Apr 24, 2007 at 09:45:54AM +0100, Simon Marlow wrote: I think the API for hooks is in need of an overhaul. I agree. 4. tools that build on Cabal (e.g. cabal-rpm) don't work with hooks. If your Setup.hs uses hooks to modify the PackageDescrption, then

Re: [Haskell-cafe] Cabal, lib and exe in one

Duncan Coutts wrote: On Tue, 2007-05-01 at 22:29 +0100, Magnus Therning wrote: So if foo.hs is in test-src and Foo/Bar.hs is in src then I think you just need: hs-source-dirs: test-src, src No, that's not enough, I also have to add the following lines to make the executable compile and link:

Re: Integrating Cabal, Haddock, HsColour

Roberto Zunino wrote: I've just extended Cabal so to generate docs with links to highlighted sources. Now ./Setup configure ./Setup haddock --link-to-hscolour ./Setup hscolour --css my_own_stylesheet.css generates HTML as this one: (run on Cabal itself) http://www.di.unipi.it/~zunino/tmp/dist/

Re: [RFC] Don't overwrite an existing Makefile

Duncan Coutts wrote: On Tue, 2007-04-24 at 10:24 -0700, Bryan O'Sullivan wrote: Hi, Simon - Another problem with "Setup makefile" is that it will overwrite an existing Makefile, even if that file perhaps ought to be present. For example, using "Setup makefile" in a Cabal repo clobbers Cabal'

Re: [PATCH] initialBuildSteps shouldn't run a complete build

Bryan O'Sullivan wrote: Hi, Simon - The "Setup makefile" refactoring you did was a little over-ambitious, and ended up doing a complete serial build before it generated any Makefile :-) In fact it appears that this was the result of Malcolm's recent changes: Tue Apr 24 11:42:44 BST 2007 [E

Re: darcs patch: Put pre-processed source into the dist/b... (and 2 more)

Duncan Coutts wrote: Those patches I was talking about. I'd apreciate a review :-) Looks fine - although as we talked about on IRC, we should think carefully about what sdist is supposed to do, and the difference between Happy/Alex-generated .hs files and c2hs-generated .hs files. The former

Cleaning up hooks

I think the API for hooks is in need of an overhaul. It has a few problems: 1. it isn't extensible. When a new command is added, typically all the Setup.hs scripts break because they haven't hooked then new command. 2. it isn't composable. It ought to be easy to augment PackageDescri

[Fwd: Bug and Features Cabal]

Forwarding on behlaf of Hans van Thiel <[EMAIL PROTECTED]>. Hello, I got this email address from the Cabal documentation page, if it should be addressed elsewhere, my apologies and please redirect me, if you can. I'd like to report my experience using Cabal for a simple distribution. 1) buildi

Re: Problems with "make" after "Setup makefile"

Bryan O'Sullivan wrote: I've had a chance to try out your makefile patch for Cabal tonight as part of pulling out cabal-rpm into a standalone program, and I'm finding problems with it. The first is with the code that attempts to use "mkdir" to create the hierarchy of object directories. It

HEADS UP: Windows Vista users

I've discovered a gotcha that happens when trying to use Cabal on Windows Vista. If you compile Setup.lhs to a binary (as I often do), with something like 'ghc --make Setup', and then try to run it, you'll get something like this: $ ./Setup configure Setup.exe: Permission denied This is d

Re: darcs patch: setup makefile

Duncan Coutts wrote: Ultimately I'd like to cabal do the dependency analysis, be able to rebuild any module (not just the lib/prog target) and do things like parallel builds. I'm well aware however that no one has the time at the moment to address that. Sure, all I did was take a little short

branches and merging

Cabal has the following branches: HEAD, in darcs.haskell.org:/cabal, used by GHC HEAD 1.1.6, in darcs.haskell.org/cabal-branches/cabal-1.1.6 GHC 6.6 branch, in darcs.haskell.org/ghc-6.6/packages/Cabal The official 1.1.6 is diverging from GHC's 6.6 version. We should merge the two - Duncan w

darcs patch: setup makefile

Distribution/Simple.hs 675 + preMakefile = readHook makefileVerbose, hunk ./Distribution/Simple.hs 726 + writeInstalledConfig pkg_descr localbuildinfo False + +defaultMakefileHook :: PackageDescription -> LocalBuildInfo + -> Maybe UserHooks -> MakefileFlags -> IO () +def

Re: darcs patch: Add preliminary support for haddock-ghc (and 9 more)

[EMAIL PROTECTED] wrote: Fri Sep 15 21:29:49 CEST 2006 [EMAIL PROTECTED] * Add preliminary support for haddock-ghc Fri Dec 29 20:54:39 CET 2006 [EMAIL PROTECTED] * Make sure haddock-ghc really creates the output dir Sun Dec 31 00:21:16 CET 2006 [EMAIL PROTECTED] * Add compilerPath to P

Re: Added RPM generation capability to Cabal

Isaac Jones wrote: Have you seen cabal2rpm? It's an external tool with a similar goal: http://community.moertel.com/ss/space/Cabal2rpm/cabal2rpm.html Similarly, there's dh_haskell for Debian packages: http://man.cx/dh_haskell(1) Can you outline any other differences between this command and c

Re: patch applied (cabal): add --enable-optimization/--disable-optimization config options (on by default)

Ian Lynagh wrote: On Tue, Feb 13, 2007 at 10:51:38AM +1100, Donald Bruce Stewart wrote: I think developers can be expected to read the docs and turn off optimisations if they like. Everyone else should get -O by default, to avoid bad press ;-) Since Duncan asked for opinions, I agree with Don.

Re: darcs patch: Add preliminary support for haddock-ghc (and 7 more)

[EMAIL PROTECTED] wrote: Fri Sep 15 21:29:49 CEST 2006 [EMAIL PROTECTED] * Add preliminary support for haddock-ghc Hi David, I had a quick chat with Duncan about this today, and we think perhaps a smoother transition path would be for haddock-ghc to be called simply "Haddock 2.0", since w

Re: Cabal bug, times two and a half

Bryan O'Sullivan wrote: Simon Marlow wrote: Bryan O'Sullivan wrote: I tried reporting a Cabal bug via Trac, but I can't log in as guest/haskell. Alas. The password is "haskell'" (note the final apostrophe). D'oh! Alas, the tick is practically invisibl

Re: Cabal bug, times two and a half

Bryan O'Sullivan wrote: I tried reporting a Cabal bug via Trac, but I can't log in as guest/haskell. Alas. The password is "haskell'" (note the final apostrophe). Isaac: maybe we should use a simpler password? The bug is that "runhaskell Setup.hs --enable-library-profiling" doesn't imply

Re: Hackage plan

Isaac Jones wrote: I added some ideas about searching / querying the package database. One idea is that I really like the way trac does querying and group-by. Once you build a query, you can also get an RSS feed based on that query. It would be pretty easy, I'd guess, to have Hackage output R

Re: haddock suggestion -- %{FILE}

Conal Elliott wrote: I did get working again by commenting out the "-optP-P" that gets passed to Haddock. Now I want to eliminate my local mod. I could easily add a another Cabal Haddock flag that says to omit the -optP-P, but I prefer the solution of checking the Haddock version number, sinc

Hackage plan

While at the Hackathon, Björn, Ross, Ian, myself and others collected some ideas for directions in which Hackage (the web interface primarily, as opposed to cabal-install) should develop. I put everything in this wiki page: http://hackage.haskell.org/trac/hackage/wiki/HackageToDo It's quit

Re: Why is there a cabal file at all?

Conal Elliott wrote: On 1/12/07, Isaac Jones <[EMAIL PROTECTED] > wrote: These tools would have to be Haskell interpreters if they wanted to read a .hs file and derive the package description from that. Thanks, Isaac. This statement helps me a lot. N

Re: new Darcs-Repository field?

Ross Paterson wrote: Björn Bringert suggested that the Hackage page for a package should include a link to the Darcs repo (if any, but who uses anything else?) and maybe some darcs integration such as changelogs and the like. To make this work, we'd need a URL-valued Darcs-Repository field in the

Re: ghc requesting package version 1.1.7 but 0.1.7 is installed ?

Marc Weber wrote: $ ghc -o setup --make -package Cabal-0.1.7 setup.hs Linking setup ... ghc-6.5.20060917: unknown package: Cabal-1.1.7 I don't understand this. I've substituted Version 1.1.7 by 0.1.7 to get a low version which won't be used unless requested. This is the only Cabal package b

Re: Cabal recompiles library for executables

Neil Mitchell wrote: If a project consists of both a library and executables, the library modules are re-compiled for each executable. (I use GHC.) That leads to high space and time consumption. Is this a bug or a feature? I also note that if a cabal project contains two programs which share

Re: Cabal recompiles library for executables

Henning Thielemann wrote: If a project consists of both a library and executables, the library modules are re-compiled for each executable. (I use GHC.) That leads to high space and time consumption. Is this a bug or a feature? A package that has both a library and executables isn't supported w

Re: Remove Setup.hs, use Setup.lhs only

Ian Lynagh wrote: On Sat, Nov 25, 2006 at 09:57:50AM -0800, Isaac Jones wrote: Ross Paterson <[EMAIL PROTECTED]> writes: On Wed, Nov 22, 2006 at 01:36:13AM +, Duncan Coutts wrote: Note that in future we intend to allow there being no Setup.(l)hs at all when using cabal-setup. No Setup.

Re: On why 'available' is evil

Ian Lynagh wrote: On Wed, Nov 01, 2006 at 02:04:29AM +, Duncan Coutts wrote: 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. I don't think anyone is arguing t

Re: sof patch for --ghc-pkg-config-file=

Isaac Jones wrote: Duncan Coutts <[EMAIL PROTECTED]> writes: On Fri, 2006-09-15 at 10:06 -0700, Isaac Jones wrote: Emailing to libraries@, please followup to cabal-devel. Here's a patch from Sigbjorn which adds --ghc-pkg-config-file= to cabal. This is an oldish patch, but I haven't stopped

Re: Configure/build separation

Isaac Jones wrote: "Krasimir Angelov" <[EMAIL PROTECTED]> writes: Since in Visual Studio there isn't a "Configure" command I decided to run configure automaticaly when the .cabal file is newer than .setup-config. The same trick can be used in cabal-setup. Does anyone care to implement this

Re: install doesn't install under Windows

Neil Mitchell wrote: Hi, prefix = c:/Program Files bindir = $prefix/Haskell/Tools datadir = $prefix/$pkgid Looks good! The MS Spec is that it should be Program Files\\, so for this I'd suggest: bindir = $prefix/Haskell/bin datadir = $prefix/Haskell/$pkgid Done. (optimisticall

Re: install doesn't install under Windows

Neil Mitchell wrote: The good and bad of each are as follows: 1) Move alex.exe into some global Haskell directory for binaries (which is on the PATH) Not too bad, but while names might not clash, if too Cabal programs both have LICENSE in their same directory, and both read it, things go wrong.

Re: issues with configurations

Duncan Coutts wrote: On Fri, 2006-08-11 at 12:15 +0100, Simon Marlow wrote: One goal (that I keep having to remind myself of) is that a .cabal file should be modifyable by an IDE such as Visual Haskell. I can't see Visual Haskell being able to successfully modify that complicated

  1   2   >