- cabal-devel - Haskell.org

[Hackage] #630: Please add support for common modules and options
by Hackage 07 Feb '10

07 Feb '10

#630: Please add support for common modules and options -----------------------------------+---------------------------------------- Reporter: AnttiJuhaniKaijanaho | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal specification | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | -----------------------------------+---------------------------------------- In some packages I have many executables that share modules and/or compilation options but I have no need for a library. In such a case it would be useful to be able to specify modules and compilation options that are common to all executables in the package. See the discussion in #89 for more context. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/630> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 07 Feb '10

07 Feb '10

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn@… | Owner: blackh Type: enhancement | Status: assigned Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.4.2 Platform: Linux | ---------------------------------+------------------------------------------ Comment(by duncan): Replying to [comment:23 AnttiJuhaniKaijanaho]: > Replying to [comment:22 duncan]: > > For ghc --make you simply get wrong results (it does not track when you change compile options). > > Which is relevant in sophisticated cases. I'm concerned that cabal makes simple things more complicated than they need to be. Just to note, this is not a model we ever intend to support in the "Simple" build system. Build systems should be purely functional. The one concession we will need to make to a purely functional description is the ability to specify exceptions that some changed input will not trigger another function to be recalculated (eg while hacking, temporarily specifying that stage1 of a compiler changing will not cause rebuild of stage2). > ... Heh. Should I be opening a separate ticket? :) Probably. A common section is not a bad thing. Note that this would not give any sharing of build results. It's just a shortcut to putting the same options in each section. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:24> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #629: cabal-install getting $arch and $os mixed up?
by Hackage 07 Feb '10

07 Feb '10

#629: cabal-install getting $arch and $os mixed up? ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ---------------------------------+------------------------------------------ In my .cabal/config I have {{{ install-dirs user prefix: /home/simonmar/.cabal bindir: $prefix/bin/$arch-$os -- libdir: $prefix/lib libsubdir: $pkgid/$compiler/$arch-$os -- libexecdir: $prefix/libexec -- datadir: $prefix/share -- datasubdir: $pkgid -- docdir: $datadir/doc/$pkgid -- htmldir: $docdir/html -- haddockdir: $htmldir }}} I just cabal-installed darcs-beta, and it said: {{{ Installing library in /home/simonmar/.cabal/lib/darcs-beta-2.3.98.3/ghc-6.12.1/linux-i386 Installing executable(s) in /home/simonmar/.cabal/bin/linux-i386 }}} so apparently it has got `$arc`h and `$os` interchanged. I think this worked in the past, because I have a `~/.cabal/bin/i386-linux` directory with some executables in it. {{{ $ cabal --version cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library }}} PS. someone needs to add Cabal version 1.8 and GHC version 6.12.1 to the relevant Trac fields -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/629> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

patch applied (cabal-branches/cabal-1.8): MERGED: Get the correct value of $topdir on Windows with GHC 6.12.1
by Ian Lynagh 04 Feb '10

04 Feb '10

Thu Feb 4 05:29:38 PST 2010 Ian Lynagh <igloo(a)earth.li> * MERGED: Get the correct value of $topdir on Windows with GHC 6.12.1 Ian Lynagh <igloo(a)earth.li>**20091230204613 This doesn't full merge the patch, as partly it changed an interface in order to refactor. M ./Distribution/Simple/GHC.hs -2 +7 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.8/_darcs/patches/2010020413…

1 0

Upgrading to cabal-install-0.8.0: messages on Windows
by José Pedro Magalhães 02 Feb '10

02 Feb '10

Hello all, When updating my cabal-install to work with ghc-6.12, I got: > cabal configure > cabal: This version of the cabal program is too old to work with ghc-6.12+. > You will need to install the 'cabal-install' package version 0.8 or higher. > If you still have an older ghc installed (eg 6.10.4), run: > $ cabal install -w ghc-6.10.4 'cabal-install >= 0.8' > > > cabal install -w ghc-6.10.4 'cabal-install >= 0.8' > cabal: "'cabal-install" is not valid syntax for a package name or package > dependency. > > > cabal install -w ghc-6.10.4 "cabal-install >= 0.8" > cabal: Cannot find the program 'ghc' at 'ghc-6.10.4' or on the path > > > cabal install -w c:\ghc\ghc-6.10.4\bin\ghc "cabal-install >= 0.8" > Resolving dependencies... (...) > Then all worked fine. Note that I had ghc-6.12.1 on the PATH and this is Windows XP 64bit. I found the first message rather informative, but unfortunately the command given does not work on Windows in general, as far as I know. For starters, the shell doesn't seem to like single quotes, but moreover, the full path to the ghc binary has to be supplied, as no symbolic links such as "ghc-6.10.4" are available. Perhaps these messages could be updated to be more helpful to Windows users? Cheers, Pedro

1 0

[Hackage] #628: Greencard files are processed incorrectly
by Hackage 01 Feb '10

01 Feb '10

#628: Greencard files are processed incorrectly ----------------------------+----------------------------------------------- Reporter: mpiechotka | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.10.1 Platform: | ----------------------------+----------------------------------------------- If I use greencard file (.gc): 1. stub files are created in source directory instead of dist 2. stub files are not compiled PS. Version is 1.8.0.2 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/628> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 01 Feb '10

01 Feb '10

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn@… | Owner: blackh Type: enhancement | Status: assigned Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.4.2 Platform: Linux | ---------------------------------+------------------------------------------ Comment(by AnttiJuhaniKaijanaho): Replying to [comment:22 duncan]: > For ghc --make you simply get wrong results (it does not track when you change compile options). Which is relevant in sophisticated cases. I'm concerned that cabal makes simple things more complicated than they need to be. > As a design choice (one made long ago) Cabal lets you specify different compile options for the same source file when used in different components. Which is a nice thing to have when you need it. > > What about allowing specifying a list of modules common to all executables? That would help me. (Or, of course, if the "private libraries" are lightweight enough that I just have to list the modules that are included in it, that's good enough.) > > That would be similar though I think I prefer the private library approach, it's a bit more flexible. The "common modules" approach does not work for sharing modules between a library and an executable with ghc because the module need to be compiled differently. Similarly, I'd like a way to specify compilation options (such as warnings) common to all executables. ... Heh. Should I be opening a separate ticket? :) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:23> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #627: Nonsense tarball permissions with sdist in Cabal 1.8.0.2
by Hackage 01 Feb '10

01 Feb '10

#627: Nonsense tarball permissions with sdist in Cabal 1.8.0.2 ----------------------------+----------------------------------------------- Reporter: draconx | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ----------------------------+----------------------------------------------- After upgrading to Cabal 1.8, running './Setup.lhs sdist' in any package is generating tarballs with bizarre permissions: - Every directory has mode 0755. - Every file has mode 0600. In particular, the executable bits from files are lost, and files should be group/world readable. Cabal 1.6 generates correct permissions. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/627> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #611: protect users from themselves when they use sudo inappropriately
by Hackage 31 Jan '10

31 Jan '10

#611: protect users from themselves when they use sudo inappropriately ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Users sometimes get themselves into trouble with sudo. For example: {{{ sudo cabal install blah }}} or {{{ sudo cabal update }}} In both cases, the user is doing actions as root that modify their normal- user files. In the first case it will install a package into ~/.cabal/ but of course all the files owned by root, so the user cannot delete them again later. In the second case cabal will as root update the per-user package index. This will make further updates not as root fail, and worse because of a file permissions bug, the index will not be readable as their normal user. The aim would be to protect users from themselves and tell them when they're doing something that's almost certainly wrong. We could suggest alternatives, like don't use sudo if you wanted to do a per-user install, or use sudo and --global if you did. The tricky bit is making a suitably accurate test and making it possible to do the silly thing, if that's what the user really really wanted. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/611> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 31 Jan '10

31 Jan '10

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn@… | Owner: blackh Type: enhancement | Status: assigned Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.4.2 Platform: Linux | ---------------------------------+------------------------------------------ Comment(by duncan): Replying to [comment:21 AnttiJuhaniKaijanaho]: > For me as a user, this feature request is obvious and it's rather disappointing that Cabal will not support it. A simple makefile-based system, or even running ghc --make by hand!, does better on this count. With the makefile you are explicitly sharing modules and you specify the compile options once for each source file. For ghc --make you simply get wrong results (it does not track when you change compile options). As a design choice (one made long ago) Cabal lets you specify different compile options for the same source file when used in different components. > What about allowing specifying a list of modules common to all executables? That would help me. (Or, of course, if the "private libraries" are lightweight enough that I just have to list the modules that are included in it, that's good enough.) That would be similar though I think I prefer the private library approach, it's a bit more flexible. The "common modules" approach does not work for sharing modules between a library and an executable with ghc because the module need to be compiled differently. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:22> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0