April 2009 - cabal-devel

[Hackage] #538: --constraint= is not respected for base
by Hackage 03 Apr '09

03 Apr '09

#538: --constraint= is not respected for base ----------------------------+----------------------------------------------- Reporter: Saizan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- the --constraint= flag apparently does nothing when the constraint involves base. e.g. to install directory-1.0.0.3, that imports Control.Exception.Base and only lists "base" in build-depends, you need to add "base >= 4", but cabal install directory --constraint="base >= 4" picks base-3.0.3.0 anyway. {{{ saizan@astarte:~/trash/directory-1.0.0.3$ cabal configure --constraint="base >= 4" Resolving dependencies... Configuring directory-1.0.0.3... 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 ISO C89... none needed checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for sys/types.h... (cached) yes checking for unistd.h... (cached) yes checking for sys/stat.h... (cached) yes configure: creating ./config.status config.status: creating include/HsDirectoryConfig.h config.status: include/HsDirectoryConfig.h is unchanged saizan@astarte:~/trash/directory-1.0.0.3$ cabal build -v Creating dist/build (and its parents) Creating dist/build/autogen (and its parents) Preprocessing library directory-1.0.0.3... Building directory-1.0.0.3... Building library... Creating dist/build (and its parents) /usr/local/bin/ghc -package-name directory-1.0.0.3 --make -hide-all- packages -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -Iinclude -optP-include -optPdist/build/autogen/cabal_macros.h -#include "HsDirectory.h" -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.3.0 -package filepath-1.1.0.1 -package old-time-1.0.0.1 -package unix-2.3.1.0 -O -XCPP -XForeignFunctionInterface System.Directory System/Directory.hs:81:7: Could not find module `Control.Exception.Base': it is a member of package base, which is hidden }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/538> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #536: c2hs needs to be given include dirs of dependent packages
by Hackage 03 Apr '09

03 Apr '09

#536: c2hs needs to be given include dirs of dependent packages ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.2 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Currently for c2hs we pass include dirs of the package itself. However for hsc2hs we also pass the include dirs of dependent packages. This is important because packages like base, rts etc have some special include dirs that we need. Especially on Windows where the mingw header files are in a special location that's recorded in the package info for base or rts. This is needed for portably binding to things in the mingw Windows header files, but also for generic posix things that happen to be defined in the mingw header files. It should not be too hard. Much of the code can be shared with the existing code for hsc2hs. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/536> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #537: c2hs needs to be told where gcc -E lives on Windows
by Hackage 03 Apr '09

03 Apr '09

#537: c2hs needs to be told where gcc -E lives on Windows ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.2 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: Windows | ------------------------------+--------------------------------------------- c2hs uses cpp or gcc -E to pre-process header files. On Windows this is not typically on the %PATH%. Cabal already knows how to find ghc's instance of gcc and how it must be called. This is already used for telling hsc2hs to use the right gcc. It should be fairly easy to do the same thing for c2hs and to share the code between the two. See also #536. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/537> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #453: "cabal fetch" should take output arguments
by Hackage 02 Apr '09

02 Apr '09

#453: "cabal fetch" should take output arguments ---------------------------------+------------------------------------------ Reporter: gregorycollins | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ---------------------------------+------------------------------------------ It would be nice if "cabal fetch" could output the fetched tarball to a location specified on the command line, i.e.: cabal fetch bytestring -o foo.tgz This probably depends on #423. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/453> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9

[Hackage] #535: Mac OS X 10.4 can't locate gmp
by Hackage 01 Apr '09

01 Apr '09

#535: Mac OS X 10.4 can't locate gmp ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Linking Setup ... /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: can't locate file for: -lgmp collect2: ld returned 1 exit status Error during cabal-install bootstrap: Compiling the Setup script failed I'm _sure_ that this has something to do with my binary ghc installation, since I found I could not compile with ghc either for the same reason. I set LD_LIBRARY_PATH to point to /sw/lib to point to the location of gmp (fink). This fixed my ghc compilation problem, but the bootstrap script still fails. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/535> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #534: cabal haddock should --hyperlink-source by default
by Hackage 01 Apr '09

01 Apr '09

#534: cabal haddock should --hyperlink-source by default ----------------------------------+----------------------------------------- Reporter: adamvo | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- The results from cabal haddock --hyperlink-source are very nice, but quite frequently the haddocks are not built with this (all recent hackage libs iirc). Would there be a problem with generating the source links by default if and only if a HsColour can be found? Or should this issue instead be resolved at the haddock level? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/534> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3