- cabal-devel - Haskell.org

patch applied (cabal): clean up createTempDirectory, using System.Posix or System.Directory
by Simon Marlow 26 Jun '09

26 Jun '09

Thu Jun 25 03:56:48 PDT 2009 Simon Marlow <marlowsd(a)gmail.com> * clean up createTempDirectory, using System.Posix or System.Directory Ignore-this: 732aac57116c308198a8aaa2f67ec475 rather than low-level System.Posix.Internals operations which are about to go away. M ./Cabal.cabal +3 M ./Distribution/Compat/TempFile.hs -10 +22 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090625105648-12142-11f8b023…

1 0

[Hackage] #458: inconsistent use of CPPFLAGS, LDFLAGS etc with build-type Configure
by Hackage 26 Jun '09

26 Jun '09

#458: inconsistent use of CPPFLAGS, LDFLAGS etc with build-type Configure ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- We have a mismatch between the cabal Setup scripts which ignore `LDFLAGS` etc and provide `--extra-lib-dirs` instead, and some `./configure` scripts which grab the `CCFLAGS` etc and bung them into a `.buildinfo` file. This is bad because it means --extra-lib-dirs does not work for those packages and it also means that those packages consult the CCFLAGS etc and others do not. It's quite an inconsistent user interface. We should try to make it more consistent. One approach would be for cabal to consider the CCFLAGS etc, to combine them with the flags passed on the command line and those specified in the .cabal file. (We have code to analyse CC/LD/CPP flags and to split them up into the standard BuildInfo fields.) Then for configure scripts we could pass the whole lot. The danger of course is that the configure scripts duplicate it all and put it into a .buildinfo file. Another tempting option is to call configure with a clean environment so that it cannot pick up these vars. Unfortunately that might break some existing packages. We should be careful with the use of these env vars though, because while it's fine to change the user interface to cabal-install, the interface to the Setup.hs is a machine interface and the more we require of it, the more has to be implemented by every different build system. A case in point is the curl package. It has a .buildinfo file like: {{{ cc-options: @CPPFLAGS@ ld-options: @LDFLAGS@ }}} The `./configure` script checks: {{{ AC_TRY_CPP([#include <curl/curl.h>],,[no_curl=yes]) }}} Which uses the `CPPFLAGS`. So it's adding an extra package-specific user interface by consulting these environment variables. At the same time the configure script ignores the `--extra-lib-dirs=` and `--extra-include-dirs=` Setup.hs command line flags. This means that users doing what is advertised will find the package does not work. Indeed changing to `build-type: Simple` and deleting the configure script makes it work perfectly. So this mismatch is clearly harmful. See also #262 which should make these checks redundant. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/458> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

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

25 Jun '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 ---------------------------------+------------------------------------------ Changes (by nomeata): * cc: nomeata (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:14> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal): follow change in System.Posix.Internals.c_open
by Simon Marlow 23 Jun '09

23 Jun '09

Mon Jun 22 06:36:54 PDT 2009 Simon Marlow <marlowsd(a)gmail.com> * follow change in System.Posix.Internals.c_open Ignore-this: d2c775473d6dfb1dcca40f51834a2d26 M ./Distribution/Compat/TempFile.hs -1 +8 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090622133654-12142-2c3cb8f3…

1 0

patch applied (cabal): update to work with the new GHC IO library internals (fdToHandle)
by Simon Marlow 23 Jun '09

23 Jun '09

Fri Jun 12 02:53:46 PDT 2009 Simon Marlow <marlowsd(a)gmail.com> * update to work with the new GHC IO library internals (fdToHandle) Ignore-this: 2697bd2b64b3231ab4d9bb13490c124f M ./Distribution/Compat/TempFile.hs +4 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090612095346-12142-95307465…

1 0

QuickCheck versions and 'cabal install'
by Stephen Blackheath [to cabal-devel] 15 Jun '09

15 Jun '09

All, I'm getting a lot of this kind of problem now that a new major version of QuickCheck has come out... blackh@amentet:~/src/projectx$ cabal install Resolving dependencies... cabal: dependencies conflict: Crypto-4.2.0.1 requires QuickCheck ==1.2.0.0 however QuickCheck-1.2.0.0 was excluded because QuickCheck-2.1.0.1 was selected instead QuickCheck-1.2.0.0 was excluded because test-framework-quickcheck2-0.2.2 requires QuickCheck >=2.1.0.0 QuickCheck-1.2.0.0 was excluded because ProjectX-0.1 requires QuickCheck >=2.1 It isn't practical to fix this properly - That would require lots of work upgrading quickcheck on all dependent packages. (Crypto-4.2.0.1 is my hacked version of Crypto-4.2.0 with a closed upper version limit to prevent it forcing QuickCheck-2.* which won't compile.) Is there a better solution to this problem? Should a package maintainer have the right to choose an old version of QuickCheck, or should cabal's policy force all package maintainers to upgrade (preferably all on the same day)? Steve

2 2

Including object files in Cabal packages
by C Rodrigues 15 Jun '09

15 Jun '09

Hi, It looks like my last post to the list got messed up somehow. I want to build a Cabal package that contains some Haskell files and one C++ file, which contains C wrappers around C++ code. I would like to compile the C++ file with a makefile, and do everything else (build, install, register, unregister) through Cabal. However, Distribution.Simple.Build.build will only build and link HS and C files; there's no way to link object files into the library. Is there a reason not to add this feature? Where should the list of object files go? I can add it as a new field of BuildInfo, or make it another parameter of build. -Chris _________________________________________________________________ Windows Live™ SkyDrive™: Get 25 GB of free online storage. http://windowslive.com/online/skydrive?ocid=TXT_TAGLM_WL_SD_25GB_062009

2 2

[Hackage] #435: ban upwardly open version ranges in dependencies on base
by Hackage 15 Jun '09

15 Jun '09

#435: ban upwardly open version ranges in dependencies on base ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- This is wrong! {{{ build-depends: base }}} This is still wrong! {{{ build-depends: base >= 3 }}} Each major release of the base package breaks most packages. Packages should specify an upper bound on the base version. Eg: {{{ build-depends: base >= 3 && < 4 }}} or equivalently: {{{ build-depends: base == 3.* }}} Cabal should check for this and suggest a sensible upper version on the base package, given that we know that base follows the package version policy. Note this is a special case for base but in general we should do this for all packages that opt-in to the versioning policy (see #343). Doing it for all such packages is a medium term goal. Doing it for base is quick and easy and has a lot of immediate benefits for the next release of base. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/435> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9

patch applied (cabal): Describe the autoconfUserHooks option more accurately in the user guide
by Duncan Coutts 14 Jun '09

14 Jun '09

Sun Jun 14 12:14:00 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Describe the autoconfUserHooks option more accurately in the user guide M ./doc/Cabal.xml -6 +9 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090614191400-adfee-8a43f78b…

1 0

patch applied (cabal): Fix && entity refs in doc xml
by Duncan Coutts 14 Jun '09

14 Jun '09

Sun Jun 14 12:12:30 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Fix && entity refs in doc xml M ./doc/Cabal.xml -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090614191230-adfee-56a96ea1…

1 0