June 2009 - cabal-devel

[Hackage] #282: profiling versions of libraries not managed well
by Hackage 30 Sep '09

30 Sep '09

#282: profiling versions of libraries not managed well ---------------------------------+------------------------------------------ Reporter: SamB | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: profiling Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ At the moment, if you want profiling builds of libraries which you have already installed, the only way to get them is to unregister and rebuild with profiling turned on. This is especially inconvenient when you have a program that depends on many different libraries... Ideally, I could just add a flag to rebuild a program with profiling, regardless of whether I'd installed profiling versions or not... Any ideas on how this should be managed? What configurations should be allowed? How do we make sure the same library version is used for the profiling build as was used for the normal build? When do we just give up and make the user figure it out? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/282> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7

[Hackage] #320: cooperation with Windows Vista's User Access Control
by Hackage 20 Sep '09

20 Sep '09

#320: cooperation with Windows Vista's User Access Control ----------------------------+----------------------------------------------- Reporter: Toxaris | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.4.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Windows | ----------------------------+----------------------------------------------- Installation of a cabal package under Windows Vista with UAC activated may fail even when working as administrator, because cabal doesn't request the necessary rights to write to, e.g., "c:\Program Files\Haskell\<whatever>". A workaround is to start an "Administrator console" to start Cabal from a process which already acquired admin privileges. Cabal should request the necessary rights instead of failing. cabal-install should check in advance whether the target destination is writeable and fail early or request the necessary rights. (currently, cabal-install fails after compiling all dependencies. After starting cabal-install again from an Administrator console, everything has to be build again). {{{ C:\Downloads\Haskell\typeof-0.1.1>runhaskell Setup install Setup: C:\Program Files\Haskell\doc\typeof-0.1.1: copyFile: permission denied (P ermission denied) }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/320> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9

[Hackage] #240: setup install does not preserve MacOS X resource forks
by Hackage 11 Sep '09

11 Sep '09

#240: setup install does not preserve MacOS X resource forks ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- I use the attached Setup.lhs file to do some Mac-related magic (which I unfortunately do not understand) on files built with wxhaskell on MacOS X. The key point about this magic is that it allows me to run a GUI from the command line. Without doing the magic, the GUI will open, but it will not react to any user interaction. I think the problem is that whatever mechanism we use to copy the binary over (say to /usr/local/bin) does not preserve the magic. That is, if I run it directly after a runhaskell Setup install, I get the non-reactive GUI. If I do a cp geni /usr/local/bin by hand, then the GUI reacts, presumably because on MacOS X cp also copies the magic over. Sorry for being so vague. Let me know if I can help in any way. -- Eric Kow -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/240> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #274: Add a 'build from sdist tarball' feature
by Hackage 23 Aug '09

23 Aug '09

#274: Add a 'build from sdist tarball' feature ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- I've often seen Darcs repos where the sdist tarball was incomplete, or where a person had a tarball which was incomplete. I think this is because most people just never use the tarball; if they do ever use it, it's because it's what was downloaded from Hackage. The reason is that doing so is much more complex than 'configure; build; install': you need to configure, create an sdist tarball, cd into dist/; do a tar -xvf or whatever of the correct tarball; cd into *that* - and then you can configure/build/install. Assuming it is a working tarball. Now, of course you can automate it. After the first dozen times, I wrote myself a shellscript to do all that for me: function build_sdist { clean_configure && sdist && cd dist/ && untar *.tar.gz && cd `ls -t ./ | grep "/" | head -n 1` && clean_configure && build && hinstall; haddock && hinstall; } (This is pretty long and imperfect, but it would be even longer if all the other aliases and function definitions were included; I think they're pretty straightforwardly named though, so I haven't included them.) It seems to me that this would be, at the very least, a useful adjunct to cabal check - if it makes sense to see whether various fields are filled out sanely, surely it makes sense to see whether needed files are included/listed? It might be even better to make the normal 'runhaskell Setup build' do it from sdist, but this is harder to code (besides the forgoing, you'd need to copy in the configuration from the top-level, from when the user ran 'runhaskell Setup configure' and added whatever options) and possibly more confusing ("But Foo.hs *is* there, right there in src/! Why can't Cabal find it?"). So I'd be satisfied to do something like 'cabal checkdist'. -- gwern -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/274> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #467: Add support for HPC profiling.
by Hackage 15 Aug '09

15 Aug '09

#467: Add support for HPC profiling. ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Similar to how we support ghc's "normal" profiling way, we should enable support to build packages with hpc turned on. This would also eliminate the need for people to add support on a per- package basis, see eg #430. See also #200. We should consider how to support these various flavours of profiling in a more extensible way. Different compilers have different ways, for example nhc has several (especially when used with hat). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/467> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #481: License compatibility check
by Hackage 05 Aug '09

05 Aug '09

#481: License compatibility check ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- It would be nice if Cabal could report license compatibility problems - e.g.: * Trying to build a BSD3-licensed package that depends on a GPL package * Trying to build a proprietary-licensed package that depends on a GPL package -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/481> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #411: Command to install dependencies of a package.
by Hackage 05 Aug '09

05 Aug '09

#411: Command to install dependencies of a package. ---------------------------------+------------------------------------------ Reporter: mornfall | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ Something like cabal install-deps or install --deps-only or such. We spoke about this with Duncan and this is the proposed solution to my use-case: I have a project that basically consists of a simple shebang haskell script (go.hs), which happens to have somewhat obscure dependencies. I am not interested in building a binary out of this script, nor installing it: but I'd like to use cabal to track and automatically install the dependencies for it. Hence, I would provide a cabal file, whose main purpose would be for people to run "cabal install-deps", which would enable them to run ./go.hs directly... Hopefully it is clear what I mean here... Don't hesitate to prod me if you have better suggestions, or, questions... -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/411> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #199: when installing a new version of GHC, there should be a way to upgrade my packages
by Hackage 18 Jul '09

18 Jul '09

#199: when installing a new version of GHC, there should be a way to upgrade my packages ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ---------------------------------+------------------------------------------ If I have version 6.6 of GHC installed, with packages foo, bar, and bang, and I install ghc 6.8, I'd like a way to automatically install foo, bar, and bang. This could be part of GHC's installation script possibly, or maybe a feature of cabal install. cabal can check the installed packages for the previous version of GHC and "cabal install" them. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/199> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 10

nice new hackage urls
by Duncan Coutts 08 Jul '09

08 Jul '09

Yay! :-) Thu Jun 11 16:40:34 BST 2009 Ross Paterson <ross(a)soi.city.ac.uk> * shorter package URL hunk ./Locations.hs 61 -pkgScriptURL = "/cgi-bin/hackage-scripts/package" +pkgScriptURL = "/package" And I see the old urls work too, presumably using the magic of apache url rewriting. Duncan

5 12

[Hackage] #564: Cabal doesn't use LD options when testing linking
by Hackage 07 Jul '09

07 Jul '09

#564: Cabal doesn't use LD options when testing linking ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- When checking to see if the C libraries are available, Cabal isn't using the LD options that it has been given. This example is using GHC's `ghc-cabal` program, but that's just a thin wrapper around the Cabal library. It looks like it's in `checkForeignDeps` in `Distribution.Simple.Configure` that it goes wrong. Note that `--ld- options="-L/usr/local/lib "` is passed, but not used in the `gcc` commands that do the linking. {{{ $ "inplace/bin/ghc-cabal" configure --with-ghc="/home/kili/src/ghc/ghc- head/inplace/bin/dummy-ghc" --with-ghc-pkg="/home/kili/src/ghc/ghc- head/inplace/bin/ghc-pkg" --with-gcc="gcc" --configure-option=--with- cc="gcc" --with-hscolour="/usr/local/bin/HsColour" --configure- option=CFLAGS="-O -I/usr/local/include " --configure- option=LDFLAGS="-L/usr/local/lib " --gcc-options="-O -I/usr/local/include " --ld-options="-L/usr/local/lib " -v3 -- dist-install libraries/integer- gmp [boring stuff skipped] ("sh",["configure","--with-compiler=ghc","--with-cc=gcc","CFLAGS=-O -I/usr/local/include ","LDFLAGS=-L/usr/local/lib "]) checking build system type... x86_64-unknown-openbsd4.5 checking host system type... x86_64-unknown-openbsd4.5 checking target system type... x86_64-unknown-openbsd4.5 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for __gmpz_fdiv_qr in -lgmp... yes configure: creating ./config.status config.status: creating integer-gmp.buildinfo config.status: creating gmp/config.mk Reading parameters from ./integer-gmp.buildinfo ("/usr/bin/gcc",["-O","-I/usr/local/include","/tmp/2499.c","-o","/tmp/2499","-O","-I/usr/local/include","-D__GLASGOW_HASKELL__=611","-I.","-I/home/kili/src/ghc /ghc-head/includes","-I/home/kili/src/ghc/ghc- head/libffi/build/include","-lgmp"]) /usr/bin/gcc returned ExitFailure 1 with error message: /usr/bin/ld: cannot find -lgmp collect2: ld returned 1 exit status ("/usr/bin/gcc",["-O","-I/usr/local/include","/tmp/2499.c","-o","/tmp/2499","-lgmp"]) /usr/bin/gcc returned ExitFailure 1 with error message: /usr/bin/ld: cannot find -lgmp collect2: ld returned 1 exit status ("/usr/bin/gcc",["-O","-I/usr/local/include","/tmp/2499.c","-o","/tmp/2499","-lgmp"]) /usr/bin/gcc returned ExitFailure 1 with error message: /usr/bin/ld: cannot find -lgmp collect2: ld returned 1 exit status ("/usr/bin/gcc",["-O","-I/usr/local/include","/tmp/2499.c","-o","/tmp/2499","-c","-O","-I/usr/local/include","-D__GLASGOW_HASKELL__=611","-I.","-I/home/kili/src/ghc /ghc-head/includes","-I/home/kili/src/ghc/ghc-head/libffi/build/include"]) ghc-cabal: Missing dependency on a foreign library: * Missing C library: gmp This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/564> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7