- cabal-devel - Haskell.org

hackage helpers!!
by Carter Schonwald 04 Jan '14

04 Jan '14

hey all, isn't there supposed to be an ACLs level for hackage helpers? (ie folks who can force docbuilders to rebuild docs for packager, edit pkg info stuff, etc?) Am I correct in thinking no ones in that group yet? (i know duncan asked for volunteers, but I don't think anyone's been put in that group yet!) cheers! -Carter

1 0

Should we aim for a new release in late January?
by Johan Tibell 19 Dec '13

19 Dec '13

Hi, Cabal development is continuing at a furious pace. There are lots of great things in master that I'd like to get out to users, such as * relinking avoidance * build -j * ability to specify exact deps on the command line * haskell-suite compiler support * bug fixes Here's an approximate list of commits (both Cabal and cabal-install) since the last release: https://github.com/haskell/cabal/compare/Cabal-v1.18.1.2...master It's not entirely accurate as some patches were cherry-picked onto the 1.18 branch and thus have different commit IDs. -- Johan

3 7

-Werror flag for Cabal?
by Peter Simons 16 Dec '13

16 Dec '13

Hi guys, is there any way to turn the following configure-time warning into a fatal error? Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. Best regards, Peter

1 0

Re: cabal: question on compiling build prerequisites
by selinger＠mathstat.dal.ca 14 Dec '13

14 Dec '13

Hi John, thanks for your reply! So say my package directory contains two files: Test.hs PreProc.hs What you are suggesting is: ghc Test.hs -F -pgmF ./PreProc However, this gives the error message: ghc: could not execute: ./PreProc And indeed, while GHC is smart enough to automatically run a preprocessor, it is not smart enough to automatically *compile* the preprocessor. So it needs to be compiled beforehand, which would be Cabal's job. But strangely, there doesn't seem to be a way to get Cabal to do this (apart from doing some very low-level hacking in the Setup.hs file). Hence my question. In a related problem, and more generally, the .cabal format seems to be lacking any way to specify things (packages, built programs) that are prerequisites of Setup.hs, as opposed to of the libraries or executables being built. So if my Setup.hs imports some non-base package, there is no way to ensure it is actually installed before Setup.hs is compiled or run. I'm ccing this to the cabal-devel list, because it's apparently a more appropriate place to discuss this than libraries(a)haskell.org. Thanks, -- Peter John Lato wrote: > > Ghc has a flag -pgmF that you can use for this. You'd need to include your > preprocessor source in the extra-source-files field of build-depends. In > this case cabal won't know anything about the preprocessor, ghc will run it > directly. > On Dec 6, 2013 7:31 PM, "Peter Selinger" <selinger(a)mathstat.dal.ca> wrote: > > > This may be a silly question, but I can't seem to find the answer in > > the documentation. > > > > I would like to create a Cabal package where some of the source files > > use a custom pre-processor. The pre-processor is itself a Haskell > > program, let's say MyPreProc.hs in the package's root directory. > > > > I figured out how to activate the preprocessor, for example, > > > > cabal build --ghc-options="-F -pgmF ./MyPreProc" > > > > I also figured out how to achieve the same effect using hooks. > > > > However, there is one problem: how can I tell cabal to actually > > compile MyPreProc.hs before any of the commands using the preprocessor > > are run? The package's Setup.hs file is automatically compiled during > > "cabal configure". I would like MyPreProc.hs to be compiled at the > > same time as well - or at least some time before the proprocessor > > needs to be used. > > > > The .cabal file contains all kinds of related variables, such as > > "build-depends" (but only packages can be listed here, not programs to > > be compiled), "other-modules" (but these modules would already require > > the pre-processor, so the pre-processor should be compiled first), > > "build-tools" (but this only refers to external programs). > > > > My current solution is to make the pre-processor a shell script, > > rather than a Haskell program. But this is ugly and not portable > > (won't work in Windows, for example). > > > > To clarify: my custom preprocessor is local to this package. It has no > > independent value, so it would not make sense to publish it as a > > separate package just so that I can add it to build-depends. > > > > Is there a known solution to this problem? > > > > Thanks, -- Peter > > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > >

3 5

Get all the processed sources for a cabal project
by Benjamin Edwards 04 Dec '13

04 Dec '13

Hi, I want to make a nice tags generator for vim that plays well with cabal sandboxes. I was wondering if there was a way to make cabal cough up all the source files for a sandboxed project taking into account the current configuration (i.e. after flags and the cpp pre-processor has been applied). If not, could anyone point me to where to look to start figuring out how to make it happen? Best, Ben

2 1

Request to release cabal-install 1.18.0.3 (Was: 2013.4.0.0 proposal
by shelarcy 11 Nov '13

11 Nov '13

Hi, cabal-install 1.18.0.2 has two critical bugs on Windows. 1. "cabal sdist" command make broken tarball on Windows. https://github.com/haskell/cabal/issues/1538 2. "cabal update" command broke package index sometimes. https://twitter.com/xyx_is/status/391944129074044929 (in Japanese) Both bugs are already fixed in 1.18 branch's cabal-install (with Cabal 1.18.1.2). But that version isn't released yet. So, please release newer version of cabal-install before releasing HP 2013.4.0.0. Best Regards, On Mon, 11 Nov 2013 01:46:18 +0900, Johan Tibell <johan.tibell(a)gmail.com> wrote: > hashable bump is good. I'm also pro shipping a newer Cabal, if it doesn't > cause any issues with the one that already comes with GHC. > > > On Sun, Nov 10, 2013 at 5:11 PM, Mark Lentczner <mark.lentczner(a)gmail.com>wrote: > >> I know it is late, and so I've done some preliminary version sleuthing.... >> Here's my proposal for HP 2013.4.0.0. I know this e-mail's is long - but >> hoping to hear from all relevant parties soon. >> >> *GHC 7.6.3* -- this is a compiler bump, but all the included packages >> remain at the same version as 2013.2.0.0 >> >> *Packages with no changes:* >> fgl, haskell-src, html, HTTP, HUnit, >> mtl, parsec, QuickCheck, random, >> regex-base, regex-compat, regex-posix, >> split, stm, text, transformers, >> xhtml, zlib >> >> *Packages with minor version bumps:* >> *I'll advance these automatically this time - no need for maintainer input* >> cgi: 3001.1.7.5 → 3001.1.8.4 >> network: 2.4.1.2 → 2.4.2.0 >> parallel: 3.2.0.3 → 3.2.0.4 >> syb: 0.4.0 → 0.4.1 >> unordered-containers: 0.2.3.0 → 0.2.3.3 >> vector: 0.10.0.1 → 0.10.9.1? >> primitive: 0.5.0.1 → 0.5.1.0? >> >> *Packages with major version bumps:* >> *I'd like to get confirmation from the maintainers of these packages that >> this bump is "the right thing to do". The bump should ideally only add API, >> and not orphan any program that used to compile under the HP - at least not >> without a good reason.* >> case-insensitive: 1.0.0.1 → 1.1.0.1 >> hashable: 1.1.2.5 → 1.2.1.0 >> >> GLUT: 2.4.0.0 → 2.5.0.1 >> GLURaw: 1.3.0.0 → 1.4.0.0 >> OpenGL: 2.8.0.0 → 2.9.1.0 >> OpenGLRaw: 1.3.0.0 → 1.4.0.0 >> >> alex: 3.0.5 → 3.1.0 >> happy: 1.18.10 → 1.19.0 >> >> *New Packages:* >> *There was prior discussion on the libraries mailing list, and generally >> all around resounding "YES!" for including aeson.* >> *I think we should include it. I'm looking for confirmation from the >> maintainer that this is the right version to include.* >> aeson: 0.6.2.1 >> >> *Cabal:* >> *The Cabal 1.18 release was a major new release, including the very very >> useful sandbox feature. This would require shipping a different Cabal lib >> than the version shipped with the included GHC. I'm not sure of the >> implications of doing this - in particular, whether we would have to ship >> two Cabal packages or just the later.* >> Cabal: 1.16.0 → 1.18.1.2 >> cabal-install: 1.16.0.2 → 1.18.0.2 >> >> What do you all think? >> >> — Mark "late, but not forgotten" Lentczner >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/

2 2

What's next?
by Johan Tibell 11 Nov '13

11 Nov '13

Hi all, With 1.18 out the door it's time to look towards the future. Here are the major themes I'd like to see us work on next: ## Faster builds There are several interesting things we could do and are doing here. * Avoid relinking if possible. This reduces incremental build times (i.e. when you run cabal build after making some change) by avoiding relinking e.g. all the test suites and/or benchmarks. See https://github.com/haskell/cabal/pull/1410 for some in-progress work. * Build components and different ways (e.g. profiling) in parallel. We could build both profiling and non-profiling versions in parallel. We could also build e.g. all test suites in parallel. The key challenge here is to coordinate all parallel jobs so we don't spawn too many. See https://github.com/haskell/cabal/pull/1413 * Build modules in parallel. This fine granularity would let us making building a single package faster, which is the most common case after all. There has been some GSoC work here e.g. http://hackage.haskell.org/trac/ghc/ticket/910 and some work by Mikhail. ## Do the right thing automatically The focus here should be on avoiding manual steps the cabal could do for the user. * Automatically install dependencies when needed. When `cabal build` would fail due to a missing dependency, just install this dependency instead of bugging the user to do it. This will probably have to be limited to sandboxes where we can't break the user's system * GHCi support could be improved by rebinding :reload to rerun e.g. preprocessors automatically. This would enable the users to develop completely from within ghci (i.e. faster edit-save-type-error cycle). We have most of what we need here (i.e. GHC macro support) but someone needs to make the final change to generate a .ghci file to pass in the ghci invocation. ## Support large projects We need to better support projects with tens or hundreds of packages. As projects grow it's naturally to split them up into a bunch of packages (libraries and executables). Some changes to the project might need changes across a couple of packages (e.g. to a supporting library and to an executable) in a single change and developers need to be able to * build several packages that have local changes, and * share changes to packages with other developers without making a release to some local Hackage server every time. Both can be done by having a single source repo with all the packages and using `cabal sandbox add-source` to make sure they get built when needed. However, that method only scales up to a handful of packages. I think we want to think about moving away from a world where all cabal commands are run in the context of some "current" package (i.e. in the current working directory). I think we want to be able to stand in the root directory of some source repo and build things from there. Example: $ git clone git://my-company/repo my-project $ cd my-project $ ls lib-pkg1 lib-pkg2 exe-pkg1 exe-pkg2 ... $ cabal sandbox init # or something similar $ edit lib-pkg1/Lib.hs $ edit exe-pkg1/Exe.hs $ cabal build exe-pkg1 # picks up changes to lib-pkg1 This has implication for many things e.g. where the .cabal-sandbo and the dist directories are kept. Perhaps dist would have a subdirectory per package (right now we do something similar for sandbox dependencies). I imagine that the syntax for e.g. cabal build would have to extended to cabal build [[DIR':']COMPONENT] Example: cabal build lib-pkg1:some-component Similar for `cabal test` and `cabal bench`. Cheers, Johan

9 16

sandbox hashcode in dist directory
by Tim Docker 10 Nov '13

10 Nov '13

I'm attempting to use ghc-mod and emacs to get on the fly compiling working again. This is always pleasing when it works, but it seems a never ending challenge to get it to find all my dependences :-( Several of my cabal packages require autogenerated code which used to end up in dist/build/autogen. ghc-mod is configured to search this directory, as per: https://github.com/kazu-yamamoto/ghc-mod/blob/169069f6232c617f06f24b9caa40f… However since starting to use cabal sandboxes, the generated code ends up in a directory like this: dist/dist-sandbox-c4c8b1d4/build/autogen/ What is this hashcode for? Is it always generated when using a sandbox? If I have code (like ghc-mod) that needs to access the build directory, how do I work out the value of the hashcode? Thanks, Tim

2 2

Compiling with --enable-shared --disable-library-vanilla
by Peter Simons 07 Nov '13

07 Nov '13

Hi guys, I'm experimenting with shared library support for Haskell in NixOS. So far, --enable-shared works great, but it comes at the cost of doubling the build times. So I tried to disable building of static libraries to fix that: $ cabal configure --enable-shared --disable-library-vanilla Resolving dependencies... Configuring funcmp-1.8... But these build won't succeed, because the in-place registration procedure can't find any *.hi files: $ cabal build ; echo $? Building funcmp-1.8... Preprocessing library funcmp-1.8... In-place registering funcmp-1.8... cabal: funcmp-1.8: file FMP.hi is missing (use --force to override) funcmp-1.8: file FMP/Canvas.hi is missing (use --force to override) funcmp-1.8: file FMP/Color.hi is missing (use --force to override) funcmp-1.8: file FMP/Core.hi is missing (use --force to override) funcmp-1.8: file FMP/File.hi is missing (use --force to override) funcmp-1.8: file FMP/Frames.hi is missing (use --force to override) funcmp-1.8: file FMP/Matrix.hi is missing (use --force to override) funcmp-1.8: file FMP/PP.hi is missing (use --force to override) funcmp-1.8: file FMP/Picture.hi is missing (use --force to override) funcmp-1.8: file FMP/RedBlack.hi is missing (use --force to override) funcmp-1.8: file FMP/Resolve.hi is missing (use --force to override) funcmp-1.8: file FMP/Symbols.hi is missing (use --force to override) funcmp-1.8: file FMP/Syntax.hi is missing (use --force to override) funcmp-1.8: file FMP/Term.hi is missing (use --force to override) funcmp-1.8: file FMP/Tree.hi is missing (use --force to override) funcmp-1.8: file FMP/Turtle.hi is missing (use --force to override) funcmp-1.8: file FMP/Types.hi is missing (use --force to override) funcmp-1.8: file Paths_funcmp.hi is missing (use --force to override) funcmp-1.8: cannot find libHSfuncmp-1.8.a on library path (use --force to override) 1 Is anyone aware of a simple remedy for this issue? Has anyone else tried this before? Can Haskell libraries be built shared-only? Best regards, Peter

2 1

cabal-install-1.18 on GHC-6.12
by Henning Thielemann 30 Oct '13

30 Oct '13

I am trying to compile cabal-install-1.18.0.2 on GHC-6.12.1. It aborts with: ... [12 of 73] Compiling Distribution.Client.Compat.Semaphore ( Distribution/Client/Compat/Semaphore.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Compat/Semaphore.o ) Distribution/Client/Compat/Semaphore.hs:12:26: Module `Control.Exception' does not export `mask_' That is, you must either narrow the dependency on 'base' or avoid 'mask_'.

5 6