- cabal-devel - Haskell.org

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

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

28 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 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. 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.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:21> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

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

28 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:19 AnttiJuhaniKaijanaho]: > From what I understand, the patch above does not solve the original request: the useless rebuilding of Other-Modules shared by multiple Executables. Right the current system does not help for packages with several executables but no library. For that we need to support convenience / private libraries as in #276. I do not plan to implement ad-hoc / implicit / opportunitsic sharing of .o files. It is too hard to implement at the moment. It requires tracking lots of information to check if the sharing is safe. It might become possible in a future build system that obsessively tracks all dependencies. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:20> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

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

27 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 | ---------------------------------+------------------------------------------ Changes (by AnttiJuhaniKaijanaho): * cc: antti-juhani@… (added) Comment: From what I understand, the patch above does not solve the original request: the useless rebuilding of Other-Modules shared by multiple Executables. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:19> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #600: Cabal should use -dynamic linking for executable when package configured --enable-shared
by Hackage 26 Jan '10

26 Jan '10

#600: Cabal should use -dynamic linking for executable when package configured --enable-shared ----------------------------+----------------------------------------------- Reporter: juhp | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ----------------------------+----------------------------------------------- With ghc-6.12 {{{--enable-shared}}} now works well to create shared libraries, however executable binary programs generated with Cabal are always statically linked. When configuring with --enable-shared they should be dynamically linked if possible. Here is a patch tested successfully with ghc-6.12 RC1 on Linux. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/600> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9

[Hackage] #623: when a package is already installed, print the version as well
by Hackage 25 Jan '10

25 Jan '10

#623: when a package is already installed, print the version as well ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ At the moment, when a package is already installed, '''cabal-install''' prints a message like the following: {{{ > cabal install 'HaXml>1.3' Resolving dependencies... No packages to be installed. All the requested packages are already installed. If you want to reinstall anyway then use the --reinstall flag. }}} It would be helpful to print the version(s) of the requested package(s) as well. One case where this would be useful is to help the user realise that a preferred-version entry is in effect - in the case above, the version of !HaXml selected would be 1.13.3, while the latest version on hackage is 1.20. The output could look like this: {{{ > cabal install 'HaXml>1.3' Resolving dependencies... No packages to be installed. All the requested packages are already installed, in particular: HaXml-1.13.3 If you want to reinstall anyway then use the --reinstall flag. }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/623> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #624: "cabal haddock" should not break my build
by Hackage 25 Jan '10

25 Jan '10

#624: "cabal haddock" should not break my build ----------------------------+----------------------------------------------- Reporter: AntoineLatter | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- See GHC bug 3799: http://hackage.haskell.org/trac/ghc/ticket/3799 With the package "syb-with-class" executing "cabal haddock" regenerates the .hi files and most of the .o files. It doesn't, however regenerate HSsyb-with-class.6.1.0.o. Since syb-with-class exports top-level declarations generated by template haskell, they have a different name every time we compile. So my (regenerated) .hi files exports names not in my .o file. If this happens during a "cabal install" we package up haddock's .hi files with the previously built HSsyb-with-class.6.1.0.o. I'm not sure if this is a Cabal bug or a haddock bug (or a GHC bug?). Either way I thought I'd post it here so people are aware of it. The work around is to turn off the auto-haddock option. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/624> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #234: track installed files to allow uninstall
by Hackage 24 Jan '10

24 Jan '10

#234: track installed files to allow uninstall -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: 6.8.2 Platform: | -----------------------------+---------------------------------------------- `cabal-install` needs to be able to track all the files it installs so that it'll be possible to uninstall packages. The copy/install code should be extended to be able to generate a list of files and hashes of files that will be installed. `cabal-install` could use that to write out a manifest file and use that later to allow uninstalling. One solution might be to restructure the install code to gather the source files that it would install rather than just doing it. Once that list of files is known we can copy them all in one go, and do other things like check for clashing target files and generate manifests etc. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/234> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 11

darcs patch: Fix #624 by making haddock put its compilation results...
by Andrea Vezzosi 22 Jan '10

22 Jan '10

Fri Jan 22 16:25:11 CET 2010 Andrea Vezzosi <sanzhiyan(a)gmail.com> * Fix #624 by making haddock put its compilation results in the temp directory. So the .hi files from the build phase don't get overwritten.

1 0

[Hackage] #625: Bad .cabal/config = "Command.optionToFieldDescr: feature not implemented"
by Hackage 19 Jan '10

19 Jan '10

#625: Bad .cabal/config = "Command.optionToFieldDescr: feature not implemented" ---------------------------------+------------------------------------------ Reporter: tommd | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ With Cabal 1.6 or 1.8.0.2 (either way) if I have a "bad" .cabal/config file, such as one with: optimization: True Then I get the error in the title. Need better error messages for broken configuration files! -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/625> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0