Re: Problems building cabal-install?

On Sat, Nov 25, 2023 at 05:23:33PM -0500, Viktor Dukhovni wrote: > > Which GHC version are you attempting to build with? My guess is that > > `cabal-install-3.4` excludes your GHC's `base` via its version > > constraints. > > No, I'm specifically using GHC 8.

Re: Problems building cabal-install?

On Sat, Nov 25, 2023 at 05:09:59PM -0500, Ben Gamari wrote: > Viktor Dukhovni writes: > > > Just, for example: > > > > $ cabal install --constraint "cabal-install ^>= 3.4" cabal-install > > > > This fails due to a conflict between Cabal-3.4 a

Re: Problems building cabal-install?

Viktor Dukhovni writes: > Just, for example: > > $ cabal install --constraint "cabal-install ^>= 3.4" cabal-install > > This fails due to a conflict between Cabal-3.4 and Cabal-syntax-3.10, > (which is not the right choice of dependency for Cabal 3.4). > &

Re: Problems building cabal-install?

On Sat, Nov 25, 2023 at 04:52:04PM -0500, Ben Gamari wrote: > > The latter shows up as a dependency of "Cabal" on hackage, but not > > in the upstream Git repo. Is there is there some sort of problem > > with the hackage metadata for Cabal 3.0, 3.2, 3.4, ... > &g

Re: Problems building cabal-install?

Viktor Dukhovni writes: > I am having a rather unexpected difficulty building older versions of > cabal-install. The invariably run into conflicts between "Cabal" and > "Cabal-syntax". > > The latter shows up as a dependency of "Cabal" o

Re: Problems building cabal-install?

On Sat, Nov 25, 2023 at 01:07:37AM -0500, Viktor Dukhovni wrote: > I am having a rather unexpected difficulty building older versions of > cabal-install. The invariably run into conflicts between "Cabal" and > "Cabal-syntax". > > The latter shows up as

Problems building cabal-install?

I am having a rather unexpected difficulty building older versions of cabal-install. The invariably run into conflicts between "Cabal" and "Cabal-syntax". The latter shows up as a dependency of "Cabal" on hackage, but not in the upstream Git repo. Is there

Re: regression in ghc / cabal integration in 9.2.1

Hi George, Have you looked at the ticket I gave you? Here's one linked from it mentioning the topic of ghc-pkg compatibility with v2-install: https://github.com/haskell/cabal/issues/6508 I'm afraid we don't have any systematic exposition of cabal history with rationale for its major changes

Re: regression in ghc / cabal integration in 9.2.1

Wasn't there specifically a new cabal version released to deal with 9.2.1? 3.4.1.0 / 3.6.2.0? On Sat, Oct 30, 2021 at 3:24 PM George Colpitts wrote: > > Thanks for the quick response Mikolaj. Sorry for the confusion, with cabal > install I did use --lib but accidentally omitted t

Re: regression in ghc / cabal integration in 9.2.1

Thanks for the quick response Mikolaj. Sorry for the confusion, with cabal install I did use --lib but accidentally omitted that in my original email. In 9.0.1 this results in a successful compilation but in 9.2.1 it does not thus I believe this is a regression. Here's the output I got in 9.2.1

Re: regression in ghc / cabal integration in 9.2.1

Hi George, Since many versions of cabal, `install` only installs executables, not libraries, so if that worked for you, you must have had an old version of cabal. Please see https://github.com/haskell/cabal/issues/6481 for some context and to help you find a new workflow that works for you

regression in ghc / cabal integration in 9.2.1

Thanks Ben! There seems to be a regression in ghc / cabal integration in 9.2.1. In 9.2.1 if I do cabal install vector Compilation of a file containing import Data.Vector main = undefined fails with Could not find module ‘Data.Vector’ Perhaps you meant Data.Functor (from base

Re: Benchmarking experiences: Cabal test vs compiling nofib/spectral/simple/Main.hs

Sebastian Graf writes: > Hi Andreas, > > I similarly benchmark compiler performance by compiling Cabal, but only > occasionally. I mostly trust ghc/alloc metrics in CI and check Cabal when I > think there's something afoot and/or want to measure runtime, not only > allo

Re: Benchmarking experiences: Cabal test vs compiling nofib/spectral/simple/Main.hs

Hi Andreas, I similarly benchmark compiler performance by compiling Cabal, but only occasionally. I mostly trust ghc/alloc metrics in CI and check Cabal when I think there's something afoot and/or want to measure runtime, not only allocations. I'm inclined to think that for my purposes (testing

Benchmarking experiences: Cabal test vs compiling nofib/spectral/simple/Main.hs

Hello Devs, When I started to work on GHC a few years back the Wiki recommended using nofib/spectral/simple/Main.hs as a test case for compiler performance changes. I've been using this ever since. "Recently" the cabal-test (compiling cabal-the-library) has become sort of a default

Re: [smartos-discuss] GHC 8.8.2 + cabal-install 3.0.0 finally working on SmartOS x64 20200117 (yet GHC 8.6.5 left less usable)

Great! And I suggest add 8.6.5 to the list, as I feel it may have wider adoption than other versions as time being, and fortunately the previous ghci problem with it has been fixed by backporting merge request 87, my repository has updated the build steps and the backporting patch. FYI. On

Re: GHC 8.6.5 now works on SmartOS - Was: GHC 8.8.2 + cabal-install 3.0.0 finally working on SmartOS x64 20200117 (yet GHC 8.6.5 left less usable)

Compl Yue via ghc-devs writes: > I verified that the problem in GHC 8.6.5 can be solved by backporting > merge request 87, a patch as well as the build steps have been updated > at https://gitlab.haskell.org/complyue/smart-ghc8, enjoy! > Great work figuring out the issue! Thanks for your work

GHC 8.6.5 now works on SmartOS - Was: GHC 8.8.2 + cabal-install 3.0.0 finally working on SmartOS x64 20200117 (yet GHC 8.6.5 left less usable)

get GHC 8.8.2 with cabal-install 3.0.0.0 working on SmartOS x64, you can checkout detailed steps and all the patches applied at https://gitlab.haskell.org/complyue/smart-ghc8 The only pity so far, is that the built GHC 8.6.5 has its `ghci` not working with a strange iconv error, and failing

GHC 8.8.2 + cabal-install 3.0.0 finally working on SmartOS x64 20200117 (yet GHC 8.6.5 left less usable)

Folks, I'm glad to report that I finally get GHC 8.8.2 with cabal-install 3.0.0.0 working on SmartOS x64, you can checkout detailed steps and all the patches applied at https://gitlab.haskell.org/complyue/smart-ghc8 The only pity so far, is that the built GHC 8.6.5 has its `ghci

GHC 8.8.1 and cabal-install 3.0 not compatible with ghc-pkg

Unfortunately ghc 8.8.1 and cabal-install 3.0 are not compatible with ghc-pkg as documented in https://github.com/haskell/cabal/issues/6262#issuecomment-538850477. As Daniel Grober wrote there: I think this is expected behaviour, at least from the cabal side of things. Version 3.0.0.0 switched

Re: [ANNOUNCE] GHC 8.8.1 and cabal-install version

I got there by doing, ``` cabal v2-install --installdir=~/.cabal/bin alex cabal v2-install --installdir=~/.cabal/bin happy ``` and things seemed to be going smoothly enough after that. On Fri, Sep 6, 2019 at 12:08 PM Carter Schonwald wrote: > V1 or v2 install? > > On Mon, Sep 2, 2

Re: [ANNOUNCE] GHC 8.8.1 and cabal-install version

V1 or v2 install? On Mon, Sep 2, 2019 at 11:42 AM George Colpitts wrote: > https://www.haskell.org/ghc/blog/20190825-ghc-8.8.1-released.html says > > cabal-install users should note that cabal-install-3.0 or later is > required for use with GHC 8.8. > > but this seems wr

Re: Cabal reports mismatched interface file ways dyn

I'm resurrecting an old thread because I thought that this might also be helpful for others. The problem I encountered was a result of old build artifacts which didn't get cleaned up. Assume you have build GHC before and now you changed something e.g. the LLVM compiler. Thus the build system

Re: Cabal reports mismatched interface file ways dyn

ick-llvm.mk > > DYNAMIC_BY_DEFAULT = YES > > > > I can build a stage3 compiler. However while executing `make install` the > > following error shows up: > > > > "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install > > "/devel/ghc86/li

Re: Cabal reports mismatched interface file ways dyn

lavours/quick-llvm.mk > DYNAMIC_BY_DEFAULT = YES > > I can build a stage3 compiler. However while executing `make install` the > following error shows up: > > "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install > "/devel/ghc86/lib/ghc-8.6.5/bin/ghc" &qu

Cabal reports mismatched interface file ways dyn

n/ghc-cabal" register libraries/ghc-prim dist-install "/devel/ghc86/lib/ghc-8.6.5/bin/ghc" "/devel/ghc86/lib/ghc-8.6.5/bin/ghc-pkg" "/devel/ghc86/lib/ghc-8.6.5" '' '/devel/ghc86' '/devel/ghc86/lib/ghc-8.6.5' '/devel/ghc86/share/doc/ghc-8.6.5/html/libraries' N

Re: Cabal woes

wrote: > Hi, > > On Mon, 15 Apr 2019 at 23:56, Simon Peyton Jones via ghc-devs > wrote: > > > > That’s a tremendously helpful summary, thank you Iavor. And Michail’s > summary was also very helpful. > > > > > > > > Most of this is doubtless wel

Re: Cabal woes

Hi, On Mon, 15 Apr 2019 at 23:56, Simon Peyton Jones via ghc-devs wrote: > > That’s a tremendously helpful summary, thank you Iavor. And Michail’s > summary was also very helpful. > > > > Most of this is doubtless well-known to habitual cabal users, but it might be

RE: Cabal woes

That’s a tremendously helpful summary, thank you Iavor. And Michail’s summary was also very helpful. Most of this is doubtless well-known to habitual cabal users, but it might be useful to explain the user model, in a way that covers these points, somewhere close to the Cabal home page

Re: Cabal woes

Hi Brandon, On Mon, 15 Apr 2019 at 23:46, Brandon Allbery wrote: > > Mikhail, the use case not addressed here is people who are used to v1-style > and want to keep using it — and possibly aren't in a great position to rewire > their setup to fit how v2 thinks. Personally, I have situations

Re: Cabal woes

But it fails this way instead, because 3.x works differently. Probably should have checked docs given it's a new major version of cabal-install. On Mon, Apr 15, 2019 at 6:44 PM Simon Peyton Jones wrote: > Simon has a cabal-install that claims to be 3.0.0.0 > > > Ah yes, I insta

Re: Cabal woes

PM Mikhail Glushenkov < mikhail.glushen...@gmail.com> wrote: > Hello Simon, > > On Mon, 15 Apr 2019 at 23:14, Simon Peyton Jones via ghc-devs > wrote: > > > > It is terribly mysterious that “cabal install hspec” doesn’t, well, > install hspec. > > In the ca

RE: Cabal woes

Simon has a cabal-install that claims to be 3.0.0.0 Ah yes, I installed it thus: ·sudo add-apt-repository ppa:hvr/ghc-wsl ·sudo apt-get update ·sudo apt install cabal-install-3.0 Why did I do that? Because earlier versions of cabal crashed with a mysterious

Re: Cabal woes

Hello Simon, On Mon, 15 Apr 2019 at 23:14, Simon Peyton Jones via ghc-devs wrote: > > It is terribly mysterious that “cabal install hspec” doesn’t, well, install > hspec. In the cabal v2-* model [1] installing libraries globally is no longer the recommended mode of operation, which i

Re: Cabal woes

Hello, in case it is useful, here is how I think about what's happening with cabal. At present, `cabal-install` supports two different modes of operation: the old style (aka `v1`) and the new style (aka `v2`) and---at least for me---the two require a slightly different mental model of what

Re: Cabal woes

The facts here are in the original message: Simon has a cabal-install that claims to be 3.0.0.0, and is treating "install" as "v2-install". So evidently *someone* has released it in some fashion, perhaps inappropriately. On Mon, Apr 15, 2019 at 6:22 PM Oleg Grenrus wrote

Re: Cabal woes

cabal-install-3 isn't released. Please check the facts. - Oleg On 16.4.2019 1.17, Brandon Allbery wrote: I vaguely recall seeing that bug come up with respect to v2-install. And in fact am a bit surprised that 3 has been released, since this is highlighting that neither it nor the Haskell

Re: Cabal woes

I vaguely recall seeing that bug come up with respect to v2-install. And in fact am a bit surprised that 3 has been released, since this is highlighting that neither it nor the Haskell ecosystem is quite ready for it. I'd also have expected (and thought I'd seen) "cabal install" in

RE: Cabal woes

Aha! That works. I would never in a million years have found that by myself. Thank you. But * It is terribly mysterious that “cabal install hspec” doesn’t, well, install hspec. * It must surely be a bug that “cabal install –lib hspec” simply crashes. Simon From: Brandon Allbery

Re: Cabal woes

Yes, I think a lot of documentation will need to be updated because this. You want "cabal v1-install" with cabal 3. On Mon, Apr 15, 2019 at 6:00 PM Simon Peyton Jones wrote: > Thanks. But alas I have no clue about whether I want a v1-install or a > v2-install, nor how to achiev

Re: Cabal woes

t; just want to install ‘hspec’ so that I can use it when compiling a > program.  How would I do that? > >   > > The instructions here https://wiki.haskell.org/Cabal-Install > <https://wiki.haskell.org/Cabal-Install> just say “cabal install > hspec” which is what I tried. 

RE: Cabal woes

Thanks. But alas I have no clue about whether I want a v1-install or a v2-install, nor how to achieve them if I knew what they were. I just want to install ‘hspec’ so that I can use it when compiling a program. How would I do that? The instructions here https://wiki.haskell.org/Cabal

Cabal woes

I'm trying to install 'hspec' on my WSL (Windows subsystem for Linux) system. But I fail; see below. For some reason cabal complains about installing a library. (That seems peculiar - isn't that what cabal is for?) But it helpfully suggests adding -lib. Alas, cabal then crashes outright, which

RE: Help with cabal

Ah, so you installed the `cabal-install-3.0` package? Yes I attached your repo and then said apt install cabal-install and lo! cabal 3.0 appeared in /opt/cabal/bin I did this because the vanilla Ubuntu distro only had cabal 1.24. And I could not update by saying “cabal install cabal-install

RE: Help with cabal

ok thanks. But still, how can I tell it to look at fpcomplete instead? And why does it do so automatically on one machine but not on another? From: ghc-devs On Behalf Of Sylvain Henry Sent: 04 April 2019 10:56 To: ghc-devs@haskell.org Subject: Re: Help with cabal Hi Simon, Hackage

Re: Help with cabal

). Small problem.  I’ve installed cabal-3.0, and say “cabal update”.  But I get Unexpected response 502for http://hackage.haskell.org/timestamp.json <http://hackage.haskell.org/timestamp.json> And indeed, that’s what a web browser says for that same URL. What do to? Oddly, on another al

Help with cabal

I'm setting up my GHC builds on a new machine, and this time I'm using WSL (windows subsystem for Linux). Small problem. I've installed cabal-3.0, and say "cabal update". But I get Unexpected response 502for http://hackage.haskell.org/timestamp.json And indeed, that's what a web br

Re: Cabal not updated after rebase?

Thank you so much Richard - it worked! And you are right, I had a `git add -u` at some point. This is what happens when I don’t review my changes closely! I had no idea I made changes to libraries/Cabal and such. Anyways, the diff is on Phab again, D5229. Hope to see feedback :) My

Re: Cabal not updated after rebase?

are/93a3f9070d5d69ad6a28fe94d20c54609698...wip/kind-app>, which is, I believe, the difference between GHC HEAD and your branch, I see that the Cabal submodule has changed. I imagine you didn't mean to do this. (This has happened to me with an ill-timed `git add -u` while rebasing. Perhaps that'

Re: Cabal not updated after rebase?

I did not touch Cabal at all, but somehow `git status` in libraries/Cabal is telling me there’s a detached HEAD? I built GHC with a fresh checkout from github, and it worked. But after applying my patch, it doesn’t work anymore. From: Richard Eisenberg Sent

Re: Cabal not updated after rebase?

Did you change the Cabal submodule at all in your work? Maybe it's out of sync somehow... What happens if you build GHC without including your changes? Does it work? > On Dec 3, 2018, at 12:13 PM, My Nguyen wrote: > > Hello, > > Thanks for the suggestion. Unfortunately, the p

Re: Cabal not updated after rebase?

Hello, Thanks for the suggestion. Unfortunately, the problem persists :(! My From: Krzysztof Gogolewski Sent: Monday, December 3, 2018 2:46 PM To: My Nguyen Cc: ghc-devs@haskell.org Subject: Re: Cabal not updated after rebase? Hi, Does `git clean -fdx

Re: Cabal not updated after rebase?

Hi, Does `git clean -fdx .` in libraries/Cabal help? git clean doesn't go into submodules. -Krzysztof On Mon, Dec 3, 2018 at 6:09 PM My Nguyen wrote: > Hi all, > > > I've finished quite a big rebase and was trying to rebuild, but it failed > with: > > ghc-cabal

Cabal not updated after rebase?

Hi all, I've finished quite a big rebase and was trying to rebuild, but it failed with: ghc-cabal: Encountered missing dependencies: Cabal ==2.5.* I then tried applying my patch on a fresh checkout of GHC and found the reason: libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:119:1:error

Re: Booting ghc with system-wide installed Cabal?

Niklas Larsson writes: > Installing stuff system-wide without doing ‘make install’ would break > my expectations for how the build works. Also, how would one return to > a pristine state if it was done that way? > Hmm, I was assuming it would be up to the user to ensure that a comp

Re: Booting ghc with system-wide installed Cabal?

Ömer Sinan Ağacan writes: > Currently we have to build Cabal from scratch after every make clean. Ideally > I > should be able to skip this step by installing the correct versions of Cabal > and cabal-install system-wide, but as far as I can see we currently doesn't > support

Re: Booting ghc with system-wide installed Cabal?

nstalling stuff system-wide without doing ‘make install’ would break my > expectations for how the build works. Also, how would one return to a > pristine state if it was done that way? > > // Niklas > > > 26 juni 2018 kl. 08:57 skrev Ömer Sinan Ağacan : > > >

Re: Booting ghc with system-wide installed Cabal?

Installing stuff system-wide without doing ‘make install’ would break my expectations for how the build works. Also, how would one return to a pristine state if it was done that way? // Niklas > 26 juni 2018 kl. 08:57 skrev Ömer Sinan Ağacan : > > Currently we have to build Cabal fro

Booting ghc with system-wide installed Cabal?

Currently we have to build Cabal from scratch after every make clean. Ideally I should be able to skip this step by installing the correct versions of Cabal and cabal-install system-wide, but as far as I can see we currently doesn't support this. Any ideas on how to make this work? Thanks, Ömer

Re: Building GHC using cabal repl

the result of making ghc relocatable: hadrian#445[1]. > It included changes to cabal and ghc and the final > bits have been merged in the form of hadrian#531[2] > just a few days ago into hadrian. The make based > build system does not take advantage of this. > > As `Config.hs` is a g

Re: Building GHC using cabal repl

Hi Joachim, I believe this might be due to the recent changes that try to keep the source tree pristine instead of generating data in-place. This is partially the result of making ghc relocatable: hadrian#445[1]. It included changes to cabal and ghc and the final bits have been merged

Building GHC using cabal repl

Hi, when hacking on most Haskell projects these days, I enjoy having a shell with ghcid -c 'cabal new-repl -w ghc-8.2' open. I wondered if I can achieve the same when hacking on GHC. The compiler/ directory has a Cabal file. It does not work out-of-the box (in a fully built tree

Re: Cabal trouble

Appending `--allow-newer=template-haskell` should tell cabal to ignore upper bounds on that package and consider more recent versions as well. In case the problem really just has to do with bounds and the code itself doesn't care, this should allow you to successfully build that package. You could

Cabal trouble

Trying to build the repro case in Trac #14208, I get this cabal install --with-ghc=/home/simonpj/5builds/ghc-8.4-branch/inplace/bin/ghc-stage2 Warning: cannot determine version of /home/simonpj/.cabal/bin/c2hs : "" Resolving dependencies... cabal: Could not resolve dependencie

NumericUnderscores extension was added to Cabal for ghc 8.6

Dear devs, The `NumericUnderscores` extension was added to Cabal for ghc 8.6. [1] I'm sending this mail referring to `BlockArguments`. [2] [1] https://github.com/haskell/cabal/pull/5130 [2] https://mail.haskell.org/pipermail/ghc-devs/2018-February/015341.html Regards, Takenobu

Re: The BlockArguments extension has been added to Cabal

Akio, thank you for telling me as well. I will also add `NumericUnderscores` extension to the Cabal library this weekend. Regards, Takenobu 2018-02-05 16:06 GMT+09:00 Akio Takano <tkn.a...@gmail.com>: > Dear GHC devs, > > The new `BlockArguments` extension has been added to th

Re: The BlockArguments extension has been added to Cabal

Akio Takano <tkn.a...@gmail.com> writes: > Dear GHC devs, > > The new `BlockArguments` extension has been added to the Cabal library. > > I'm sending out this notification because the Note [Adding a language > extension] in compiler/main/DynFlags.hs asks me to do so. >

Re: GHC Build System & Cabal

Hi, Am Freitag, den 21.04.2017, 11:29 +0800 schrieb Moritz Angermann: > Initially I expected we’d just > shell out and let cabal do the configuration and building of > .cabal’ised > packages.  But it seems to be the case that we sidestep cabal for > building > ghc. one reason

GHC Build System & Cabal

Dear friends, I’m currently exploring the possibility to build two versions of base similar to how we build various ways of the rts. The reasons for doing this won’t add much to the discussion. Reading https://ghc.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/Cabal I find the following

install pandoc with cabal update

hello y try to install pandoc in mode offline but the standard installation from source preconise to execute cabal update . it seems that cabal update try to connect and download package from hackage.haskell.org. do you known how to execute offline installation ? ghc 7.10.3 cabal 1.24.0.0

RE: cabal

Thanks Brandon. But I think Ben was probably right; I need cabal install cabal-install. Somehow this ought to be easier. I’ll try that when I next get a chance SImion From: Brandon Allbery [mailto:allber...@gmail.com] Sent: 05 September 2016 17:50 To: Simon Peyton Jones <s

Re: cabal

On Mon, Sep 5, 2016 at 12:40 PM, Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > bash$ which cabal > > /home/simonpj/.cabal/bin/cabal > > Maybe I need 1.24. Which claims to be installed. But WHERE is it > installed? > > Try "type cabal".

cabal

I’m trying to follow the instructions for https://ghc.haskell.org/trac/ghc/ticket/12562 But I get cabal new-build llvm-general --with-ghc=/home/simonpj/5builds/HEAD-4/inplace/bin/ghc-stage2 cabal: unrecognised command: new-build (try --help) simonpj@cam-05-unx:~/tmp/llvm-general$ Maybe my

Re: GHC HEAD compile failure at ghctags: "missing: Cabal >=1.25 && <1.27"

a GHC 7.10.3) from freshly git-pulled > HEAD, > > and "make" keeps dying at ghctags: > > > > Configuring ghctags-0.1... > > ghc-cabal: At least the following dependencies are missing: > > Cabal >=1.25 && <1.27 > > > >

Re: GHC HEAD compile failure at ghctags: "missing: Cabal >=1.25 && <1.27"

Don't forget to "git submodule update" Edward Excerpts from Conal Elliott's message of 2016-03-30 10:02:20 -0700: > I'm trying to recompile GHC (via GHC 7.10.3) from freshly git-pulled HEAD, > and "make" keeps dying at ghctags: > > Configuring ghctags-

GHC HEAD compile failure at ghctags: "missing: Cabal >=1.25 && <1.27"

I'm trying to recompile GHC (via GHC 7.10.3) from freshly git-pulled HEAD, and "make" keeps dying at ghctags: Configuring ghctags-0.1... ghc-cabal: At least the following dependencies are missing: Cabal >=1.25 && <1.27 According to ghc-pkg I have Cabal

Re: Installing Cabal for GHC 8.0 release candidates

George Colpitts writes: > works for me, on my Mac > Thanks for the confirmation, George! Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org

Re: Installing Cabal for GHC 8.0 release candidates

works for me, on my Mac On Tue, Feb 16, 2016 at 9:44 AM Ben Gamari <b...@well-typed.com> wrote: > > Hello everyone, > > Our wonderful Cabal release manager Mikhail Glushenkov has kindly > uploaded candidate releases of Cabal and cabal-install for use by GHC > 8.0 rele

Installing Cabal for GHC 8.0 release candidates

Hello everyone, Our wonderful Cabal release manager Mikhail Glushenkov has kindly uploaded candidate releases of Cabal and cabal-install for use by GHC 8.0 release candidate users. Now updating to a GHC 8.0-compatible Cabal/cabal-install should be as simple as, cabal install \ http

GHC 8.0 Migration Guide & Ubuntu GHC8/cabal packages (was: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1)

I'd also like to remind you that (more or less) daily snapshots of GHC 8.0.1 for Ubuntu {Precise,Trusty,Vivid,Wily} are already available via https://github.com/hvr/multi-ghc-travis This also includes a "cabal-install-1.24" package (which currently contains the current lat

Re: Cabal status for GHC 8.0.1

Hi, On 12 January 2016 at 17:50, Ben Gamari <b...@well-typed.com> wrote: > Within what timeframe in particular do you think we'll > be able to have a release tagged and (and ideally released)? Is late > January possible? Yes, I think it should be possible. In fact, all Cabal

Cabal status for GHC 8.0.1

Hello everyone, As you likely know the GHC 8.0.1 release is quickly approaching. The release candidate should be out any moment now and we anticipate a final release in mid-February. Consequently, we should start thinking about how we will manage the Cabal release. Duncan has said that his nix

Problems with cabal

Hi, everyone! I have a strange problems with building GHC from sources. I cloned git repo as said in newcomers' page, but i have that kind of error: Cloning into 'libraries/Cabal'... fatal: repository 'https://github.com/ghc/packages/Cabal.git/' not found Clone of 'http://github.com/ghc/packages

Re: Problems with cabal

rote: > Hi, everyone! > > I have a strange problems with building GHC from sources. I cloned git > repo as said in newcomers' page, but i have that kind of error: > > Cloning into 'libraries/Cabal'... fatal: repository ' > https://github.com/ghc/packages/Cabal.git/' not found Clo

Please help beta test no-reinstall Cabal (was: Cabal and simultaneous installations of the same package)

Good news, everyone! ...you may be interested to know this has finally come to fruition (just in time for HIW): http://blog.ezyang.com/2015/08/help-us-beta-test-no-reinstall-cabal/ Cheers, hvr On 2015-03-23 at 09:45:48 +0100, Simon Peyton Jones wrote: Dear Cabal developers You'll

Re: Compiling cabal with GHC HEAD

Yes, this is a common hazard when trying to use cabal-install with GHC HEAD. My recommendation is to use the Cabal tip distributed with GHC HEAD. Edward Excerpts from Oleg Grenrus's message of 2015-08-26 12:29:16 -0700: Ah, so this happens because GHC HEAD has Cabal-1.23.0.0 bundled with it. I

Re: Compiling cabal with GHC HEAD

Ah, so this happens because GHC HEAD has Cabal-1.23.0.0 bundled with it. I see. And as Cabal master is also 1.23.0.0 they don’t really work together (i.e. cabal-install uses system Cabal). Ok, maybe we can wait till GHC’s Cabal reference-commit will be bumped, if not already. Thanks

Re: armv7 invalid instruction problem building cabal

Ben Burdette wrote: I've been trying to get going with ghc 7.10.2 on armv7 debian, problem is described here: http://stackoverflow.com/questions/32124334/ghc-armv7-binary-cabal-illegal-instruction Sorry, I'll answer here instead of SO if thats OK. Mostly because I don't have an answer

Re: armv7 invalid instruction problem building cabal

On 08/21/2015 03:16 PM, Erik de Castro Lopo wrote: Ben Burdette wrote: I've been trying to get going with ghc 7.10.2 on armv7 debian, problem is described here: http://stackoverflow.com/questions/32124334/ghc-armv7-binary-cabal-illegal-instruction Sorry, I'll answer here instead of SO

Re: armv7 invalid instruction problem building cabal

Ben Burdette wrote: No prob! Either forum is ok for me. get info output: Ok, this: ,(ld command,/usr/bin/ld.gold) means GHC uses ld.gold explicitly and this ,(LLVM llc command,/usr/bin/llc-3.5) ,(LLVM opt command,/usr/bin/opt-3.5) means its using the right versions of the llvm

Re: armv7 invalid instruction problem building cabal

Ben Burdette wrote: I've been trying to get going with ghc 7.10.2 on armv7 debian, problem is described here: http://stackoverflow.com/questions/32124334/ghc-armv7-binary-cabal-illegal-instruction I suspect your problem may be related to this one: https://ghc.haskell.org/trac/ghc

Re: armv7 invalid instruction problem building cabal

On 08/21/2015 04:00 PM, Erik de Castro Lopo wrote: Ben Burdette wrote: I've been trying to get going with ghc 7.10.2 on armv7 debian, problem is described here: http://stackoverflow.com/questions/32124334/ghc-armv7-binary-cabal-illegal-instruction I suspect your problem may be related

Compiling cabal with GHC HEAD

I tried to fix compilation of Cabal using Cabal HEAD. It’s trivial patch: https://github.com/phadej/cabal/commit/525e0680505c74f42a321e55b357a27222790628 but it breaks build on every other released GHC: https://travis-ci.org/phadej/cabal/builds/76288656 — The original issue GHC-7.11

Re: Compiling cabal with GHC HEAD

Oh, this is irritating. The problem is we recently updated Cabal the library to get rid of InstalledPackageInfo_ (so there is only InstalledPackageInfo now) but it looks like in some situations cabal-install can be compiled with an old version of Cabal (as is happening to you). I suppose

Re: [GHC] #10627: Regression: cabal install of numeric-prelude hangs

be good to know if this bug is specific to the Mac platform. Thanks George On Fri, Jul 10, 2015 at 5:51 PM, GHC ghc-devs@haskell.org wrote: #10627: Regression: cabal install of numeric-prelude hangs -+- Reporter

Re: Cabal and simultaneous installations of the same package

to deal with this, but extending Cabal to do this is out of scope for the GSOC. Edward ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: QRE: Cabal and simultaneous installations of the same package

: Boespflug, Mathieu; Gershom B; Mikhail Glushenkov; Duncan Coutts (dun...@well-typed.com); Ryan Trinkle; haskell-infrastruct...@community.galois.com; cabal-de...@haskell.org; ghc-devs@haskell.org; Haskell Libraries Subject: Re: QRE: Cabal and simultaneous installations of the same package Yes

RE: QRE: Cabal and simultaneous installations of the same package

packages in the environment are compatible; they won’t give rise to the confusing “P-2.3:M.T does not match P-2.4:M.T” errors. ·The environment is irrelevant when cabal is installing a package,. Cabal just computes a set of consistent dependencies, installs any missing dependencies

RE: Cabal and simultaneous installations of the same package

I see this as mission-critical to relieving Cabal hell. (Am I alone?) So it’s great that Vishal is going to work on it. Go Vishal! Can I take it, then, that the Cabal developers will be sufficiently involved that, assuming there are no show-stopping problems, they’ll accept the patch

Re: Cabal and simultaneous installations of the same package

Hi Simon, It is tantalising to me that something so critical has been so long delayed. It’d be fantastic if it was done this summer. I'm just wondering what kind of negative side effects it might have. Sure, it will - most likely - make installing of cabal packages a lot easier, especially

  1   2   3   >