May 2009 - cabal-devel

haddock-2.3.0 literate comments discarded from .lhs input
by Alistair Bayley 27 May '09

27 May '09

I have this test case for Haddock (2.3.0): -------------------------------------------------- | Module : Test.Haddock Copyright : (c) 2009 Alistair Bayley License : BSD-style Maintainer : alistair(a)abayley.org Stability : stable Portability : portable Test case for Haddock. > module Test.Haddock > ( > -- $named_block > Fail(..) > ) > where > data Fail = Fail | Succeed $named_block This is some hadock documentation. -------------------------------------------------- This fails with: [1 of 1] Compiling Test.Fail ( Test\Fail.hs, Test\Fail.o ) Test\Fail.hs:11:26: Can't make a derived instance of `Typeable Fail' (You need -XDeriveDataTypeable to derive an instance for this class) In the data type declaration for `Fail' If I manually unlit, then Haddock is happy: -------------------------------------------------- -- | -- Module : Test.Haddock2 -- Copyright : (c) 2009 Alistair Bayley -- License : BSD-style -- Maintainer : alistair(a)abayley.org -- Stability : stable -- Portability : portable -- -- Test case for Haddock. module Test.Haddock2 ( -- $named_block Fail(..) ) where data Fail = Fail | Succeed -- $named_block -- -- This is some hadock documentation. -------------------------------------------------- so it looks as though it's discarding the literate comments. Is this intended? I was under the impression that because it used the ghc parser, it could now properly handle .lhs input. Ona related note, we have a nice unlitter in cabal that would preserve these comments before invoking haddock. Is this still used with haddock2, or does it now assume haddock2 will do the right thing? Alistair

5 27

Working on a fix for ticket #89
by Stephen Blackheath [to cabal-devel] 25 May '09

25 May '09

All, I'm working on a fix for ticket #89 (http://hackage.haskell.org/trac/hackage/ticket/89) and I have a specific question for the list: ---- If I do this... build-depends: base Library build-depends: bytestring ...then when the library compiles, it will fail to find the Prelude (i.e. -package base doesn't get passed to ghc). Is there a reason why the global 'build-depends' doesn't add to all targets (i.e. all exes & libs)? That's what I would expect it to do, but that might be just me. Or more to the point, should this be fixed? ---- The code changes I'm working on also fix a couple of other things, so this is the complete list: - Ticket #89: Make it so the executable can depend on the library defined in the same package. If hs-source-dirs is used, you can avoid it compiling the .hs files multiple times. - Make it so build-depends: defined in a Library or Executable block affects only the build of those components, not all components as currently happens. For avoidance of package breakage, this behaviour only happens if you specify cabal-version: >= 1.7 (that is, versions less than 1.7 are entirely excluded). - Make a really simple unit test harness using the test-framework package, and add some test cases for the new behaviour. The idea is that we can gradually integrate existing tests (hunit & quickcheck) into it. - Make UnitTests compile (though hardly any of the tests pass). This patch is not yet tidy enough to submit, but it is complete enough to actually work for GHC. I would welcome any comments. Here it is (against HEAD): http://upcycle.it/~blackh/cabal/cabal-ticket-89-v3.patch Steve

2 5

[Hackage] #554: HStringTemplate fails to build when building gitit
by Hackage 24 May '09

24 May '09

#554: HStringTemplate fails to build when building gitit ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: cabal-install-0.6 Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Fresh install of GHC (6.10.3), cabal (1.6.0.2) and cabal-install (0.6.2). Ran the command: cabal install -fhighlighting gitit And saw the following error: Linking dist/build/pandoc/pandoc ... Created man/man1/pandoc.1 Created man/man1/hsmarkdown.1 Created man/man1/html2markdown.1 Created man/man1/markdown2pdf.1 Installing library in /Users/njritter/.cabal/lib/pandoc-1.2/ghc-6.10.3 Installing executable(s) in /Users/njritter/.cabal/bin Registering pandoc-1.2... Reading package info from "dist/installed-pkg-config" ... done. Writing new package config file... done. cabal: Error: some packages failed to install: HStringTemplate-0.5.1.1 failed during the building phase. The exception was: exit: ExitFailure 1 gitit-0.5.3 depends on HStringTemplate-0.5.1.1 which failed to install. cletus:cabal-install-0.6.2 njritter$ cabal install -fhighlighting -fciteproc gitit Resolving dependencies... Configuring HStringTemplate-0.5.1.1... Preprocessing library HStringTemplate-0.5.1.1... Building HStringTemplate-0.5.1.1... Text/StringTemplate/GenericStandard.hs:12:7: Could not find module `Data.Generics.Aliases': it was found in multiple packages: base-3.0.3.1 syb cabal: Error: some packages failed to install: HStringTemplate-0.5.1.1 failed during the building phase. The exception was: exit: ExitFailure 1 gitit-0.5.3 depends on HStringTemplate-0.5.1.1 which failed to install. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/554> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Re: [Hackage] #555: mandir is totally busted (wrong, and ignores --destdir)?
by Hackage 24 May '09

24 May '09

#555: mandir is totally busted (wrong, and ignores --destdir)? --------------------------------------------------+------------------------- Reporter: Trent W. Buck <trentbuck(a)gmail.com> | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Resolution: fixed Keywords: mandir | Difficulty: unknown Ghcversion: 6.10.1 | Platform: Linux --------------------------------------------------+------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: Thanks for the report. You'll be glad to know it has been fixed already and the fix made it into the 1.6.0.2 release. If you still find the problem in the later release then please reopen this ticket. {{{ Tue Feb 3 04:33:38 GMT 2009 Samuel Bronson <naesten(a)gmail.com> * Correct docdir -> mandir in InstallDirs hunk ./Distribution/Simple/InstallDirs.hs 287 - mandir = subst docdir (prefixBinLibDataVars ++ [docdirVar]), + mandir = subst mandir (prefixBinLibDataVars ++ [docdirVar]), }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/555#comment:5> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #555: mandir is totally busted (wrong, and ignores --destdir)?
by Hackage 24 May '09

24 May '09

#555: mandir is totally busted (wrong, and ignores --destdir)? --------------------------------------------------+------------------------- Reporter: Trent W. Buck <trentbuck(a)gmail.com> | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: mandir | Difficulty: unknown Ghcversion: 6.10.1 | Platform: Linux --------------------------------------------------+------------------------- Comment (by guest): Hmm, if I change NoCopyDest to (fromFlag $ copyDest flags), then it does use --destdir correctly. So the only real issue here is that it's using a silly default $mandir, where "silly" means different to what man(1) expects and autotools uses. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/555#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #555: mandir is totally busted (wrong, and ignores --destdir)?
by Hackage 24 May '09

24 May '09

#555: mandir is totally busted (wrong, and ignores --destdir)? --------------------------------------------------+------------------------- Reporter: Trent W. Buck <trentbuck(a)gmail.com> | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: mandir | Difficulty: unknown Ghcversion: 6.10.1 | Platform: Linux --------------------------------------------------+------------------------- Changes (by guest): * reporter: guest => Trent W. Buck <trentbuck(a)gmail.com> -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/555#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #555: mandir is totally busted (wrong, and ignores --destdir)?
by Hackage 24 May '09

24 May '09

#555: mandir is totally busted (wrong, and ignores --destdir)? ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: mandir Difficulty: unknown | Ghcversion: 6.10.1 Platform: Linux | ----------------------------+----------------------------------------------- Consider the following transcript. Why is Cabal ignoring --destdir, and why does mandir default to \$prefix/share/doc/foo-1 instead of \$prefix/share/man? $ darcs get http://twb.ath.cx/tmp/tinc Finished getting. $ darcs check --test --repo tinc [...] + ./Setup copy --verbose --destdir=/tmp [...] Creating /usr/local/share/doc/foo-1/man1 (and its parents) Setup: /usr/local/share/doc: createDirectory: permission denied (Permission denied) Test failed! In case my dummy repo goes away, it is quite simple: == Setup.hs == import Distribution.Simple import Distribution.Simple.LocalBuildInfo import Distribution.Simple.Setup import Distribution.Simple.Utils import System.FilePath {- Copy ./Setup.hs into $mandir/man1. $mandir *ought* to be $destdir/share/man. It sure as shit shouldn't be /usr/local if I set --destdir=/tmp, and it shouldn't be $destdir/share/doc/$package/man. -} main :: IO () main = defaultMainWithHooks simpleUserHooks { postCopy = \ _ flags pkg lbi -> copyFiles (fromFlag $ copyVerbosity flags) (mandir (absoluteInstallDirs pkg lbi NoCopyDest) </> "man1") [(".", "Setup.hs")]} == foo.cabal == Name: foo version: 1 Build-Type: Custom Cabal-Version: >= 1.6 Executable Setup main-is: Setup.hs build-depends: base, filepath, Cabal changepref test == test == set -ex; ghc -Wall --make Setup; ./Setup configure; ./Setup build; ./Setup copy --verbose --destdir=/tmp -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/555> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

--global for bootstrap.sh
by Jason Dusek 20 May '09

20 May '09

I'm not sure whether this will have the desired effect in all cases; however, it works for me. I've long desired a `--global` installation for cabal and this seems to at least get the bootstrap right. -- Jason Dusek diff -rN old-cabal-install/bootstrap.sh new-cabal-install/bootstrap.sh 20a21,38 > SCOPE_OF_INSTALLATION="--user" > > > for arg in $* > do > case "${arg}" in > "--user") > SCOPE_OF_INSTALLATION=${arg} > shift;; > "--global") > SCOPE_OF_INSTALLATION=${arg} > PREFIX="/usr/local" > shift;; > *) > echo "Unknown argument or option, quitting.\n ${arg}" > exit;; > esac > done 135c153 < ./Setup configure --user "--prefix=${PREFIX}" \ --- > ./Setup configure ${SCOPE_OF_INSTALLATION} "--prefix=${PREFIX}" \

1 0

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 19 May '09

19 May '09

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn(a)bringert.net | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ---------------------------------+------------------------------------------ Comment (by guest): Here's my patch to fix this issue, which Duncan is reviewing for me: http://upcycle.it/~blackh/cabal/cabal-ticket-89-v5.darcs-send - Stephen Blackheath -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:12> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #553: wish: Have "setup configure" unconditionally pass options like --prefix to user-supplied configure script.
by Hackage 18 May '09

18 May '09

#553: wish: Have "setup configure" unconditionally pass options like --prefix to user-supplied configure script. ----------------------------+----------------------------------------------- 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: | ----------------------------+----------------------------------------------- Cabal's "setup configure" can be made to run a user-supplied configure script. When so instructed, it passes command line options like --prefix along to that configure script. However, if no --prefix is given by the user, no --prefix option is passed along to the configure script either. This means that such a configure script cannot actually do anything with the prefix unless it is willing to make assumptions about what the default prefix is when none is specified. It would be better if Cabal passed the configure script a --prefix option (and maybe others) regardless of whether the user specified one, so that the script always has the real prefix available. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/553> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1