testing cabal-install-0.25.2 with ghc-7.6.1

Hi, I managed to build cabal-install-0.25.2 (from the cabal-1.16 branch) with ghc-7.6.1 Cabal. However the use of viewAsFieldDescr in cabal-install/Distribution/Client/Config.hs causes problems due to the: error Command.optionToFieldDescr: feature not implemented in Cabal-1.16.0, so I am not

Re: testing cabal-install-0.25.2 with ghc-7.6.1

On 15 September 2012 11:35, Mikhail Glushenkov the.dead.shall.r...@gmail.com wrote: Can it be so that ghc-7.6.1 ships with an older snapshot of Cabal-1.16? Indeed Try building cabal-install using revision e7e7ce1029707a67d26e6dc29de11141734898e3 I don't doubt that it builds with the Cabal in

Re: testing cabal-install-0.25.2 with ghc-7.6.1

Hi I think with the attached backport patch it is possible at least to build the cabal-install-0.15.1 source included in ghc-7.6.1's src tarball with ghc-7.6.1. Jens On 15 September 2012 11:35, Mikhail Glushenkov wrote: Can it be so that ghc-7.6.1 ships with an older snapshot of Cabal-1.16?

Hackage updating of distro data

Hi, it is great that Hackage 2 finally was deployed in production. :-) How often does Hackage 2 update/pull distro data? Hackage 1 had a cronjob I believe which ran every few hours I think. But the new Hackage does not seem to pull often/regularly. For Fedora I updated the data on 18 Sept and

hackage reverse dependencies

Not really complaining :) but one of the things I had been looking forward to with Hackage2 was the display of reverse-dependencies, but I gather it was disabled for now (because it loads the server too much when updating the data iirc?). I was thinking perhaps a compromise would be to show only

Re: Hackage updating of distro data

Hi Matt, thanks for your detailed mail. On 14 October 2013 17:04, Matthew Gruen wikigraceno...@gmail.com wrote: Distro maintainers can upload distro information directly to Hackage (either manually, using a form, or programmatically using something like curl). It is currently not exposed or

Re: cabal-install-1.18 on GHC-6.12

On 28 October 2013 18:39, Herbert Valerio Riedel h...@gnu.org wrote: Btw, are there any Linux distribution release out there which have not reached end-of-life and yet provide GHC 6.12.x as their default GHC? (The EPEL 5 repo for RHEL5 and derivatives still has ghc-6.12.3 but RHEL5 is also

Re: Cabal-1.18.1.3 and cabal-install-1.18.0.3 releases made

On 5 March 2014 06:28, Johan Tibell johan.tib...@gmail.com wrote: I've just made a release of Cabal/cabal-install, for the benefit of GHC 7.8. Thanks!! I have now built them for Fedora 19 and 20 in my Fedora Copr repos: https://copr.fedoraproject.org/coprs/petersen/cabal-install/

Re: Needed: distributable executables for the 1.20 release

Hi! I built cabal-1.20.0.0 for Fedora 19 and 20 in my copr repo: https://copr.fedoraproject.org/coprs/petersen/cabal-install/ Thanks, Jens ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

Re: Windows executable for just released cabal-install-1.20.0.1 needed

BTW, the Windows exe I sent you was 32-bit, unlike what it says on the download page. BTW I just noticed that http://www.haskell.org/cabal/download.html now says that ghc-7.8.1 ships with Cabal-1.20.0.0 whereas in fact it still ships with 1.18.1.3. (I imagine that the sentence was

Fedora Copr repo updated to cabal-install-1.20.0.1

I updated my Fedora Copr repos to cabal-install-1.20.0.1 (though due to some copr flakiness the build failed somehow on F20 i686). https://copr.fedoraproject.org/coprs/petersen/cabal-install/ On 4 May 2014 09:25, Johan Tibell johan.tib...@gmail.com wrote: It's that time again. 1.20.0.1 is out

passing CFLAGS and LDFLAGS to ghc via Cabal?

Hi, This may seem like a strange question since most ghc compilation uses the NCG or llvm backends, but I want to ask about how/if one can pass CFLAGS/LDFLAGS to gcc from Cabal? So far I tried using --gcc-options=$RPM_OPT_FLAGS (and also just exporting CFLAGS), but as far as I can tell (from

Re: passing CFLAGS and LDFLAGS to ghc via Cabal?

On 25 October 2014 05:10, Sergei Trofimovich sly...@gmail.com wrote: I believe the proper way to pass them is via --ghc-option=-optc$EACH_CFLAG -optl$EACH_LDFLAG -opta$EACH_ASFLAG as Cabal uses ghc to compile .c/.cpp files. Thanks Sergei that helped a lot. :) I can now get proper

making cabal-install into a library?

Hi, For a while I have been thinking cabal-install should really be a library. Has anyone considered or thought about this? I am wondering how much work it may be? Best wishes, Jens ___ cabal-devel mailing list cabal-devel@haskell.org

Cabal-1.22 keyed library filepaths

Hi, I see that with Cabal-1.22, library paths are now of the form: /usr/lib64/ghc-7.10.0.20141222/direc_3m6Ew9I164U5MIkATLCdb8/ libHSdirec_3m6Ew9I164U5MIkATLCdb8-ghc7.10.0.20141222.so etc. Is the 5 character truncation of package names (and no version) necessary? It makes it pretty hard to

Re: making cabal-install into a library?

Sorry Carl I missed your reply... On 3 January 2015 at 02:03, Carl Eyeinsky eyeins...@gmail.com wrote: Can you explain what you mean, or how would you use it? E.g do you mean having the cabal commands as functions, into which you can pass a directory structure (with file contents included)

Re: Cabal-1.22 keyed library filepaths

Hi Edward, On 9 February 2015 at 07:10, Edward Z. Yang ezy...@mit.edu wrote: Jens, could file a Cabal bug for the contents of this email? I opened https://github.com/haskell/cabal/issues/2437. Sorry for the delay, I was travelling and just saw your mail now. Thanks, Jens