April 2010 - cabal-devel

patch applied (cabal): Add the hs output dir to the C include dirs when compiling C code
by Duncan Coutts 24 Apr '10

24 Apr '10

Wed Apr 21 17:11:01 PDT 2010 Duncan Coutts <duncan(a)haskell.org> * Add the hs output dir to the C include dirs when compiling C code This allows C files in a package to include the _stub.h files that ghc generates. This is needed for the C code to be able to call the C functions exported using the FFI. M ./Distribution/Simple/GHC.hs -1 +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

patch applied (cabal): Add the autogen dir to the C include dirs when checking foreign libs
by Duncan Coutts 24 Apr '10

24 Apr '10

Wed Apr 21 17:09:08 PDT 2010 Duncan Coutts <duncan(a)haskell.org> * Add the autogen dir to the C include dirs when checking foreign libs This allows packages to generate .h files and stick them in the autogen dir, and still have local .h files include those generated header files. Used in gtk2hs. M ./Distribution/Simple/Configure.hs +3 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

Re: [Hackage] #93: Incorrect permissions on library install
by Hackage 23 Apr '10

23 Apr '10

#93: Incorrect permissions on library install ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.1.4 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.10.1 | Platform: Linux ----------------------------+----------------------------------------------- Comment(by svat2): This bug still exists, it is not restricted to library installs or to Unix, and is a big nuisance. My OS is Mac OS X, user umask is 077, cabal version is "cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library". I set my cabal to global installs, and did `sudo cabal install pandoc`. A lot of files (including the binary itself) were installed with incorrect permisssions, so I (as user) couldn't run the program. I tried changing umask and reinstalling with `sudo cabal --reinstall install pandoc`, but it didn't fix permissions. (Possibly because my root umask also appears to be 077 for some reason.) Doing `sudo chmod -vR a+rX /usr/local` was the workaround that finally helped. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/93#comment:9> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #288: the package indexes are very slow
by Hackage 23 Apr '10

23 Apr '10

#288: the package indexes are very slow ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ Comment(by duncan): The installed package index is now respectably fast. The available index is still slow. Here's one approach: instead of generating a full cache in an alternative format, generate an index of the tarball mapping package id to offset, length pairs in the uncompressed .tar file. Then we can lazily load the tarball. Ideally just mmap it and extract the offset,length slices and lazily parse. It would avoid loading the full 20+ megabytes of the full index. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/288#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #664: incorrect dependencies for packages with both library and executable in them
by Hackage 23 Apr '10

23 Apr '10

#664: incorrect dependencies for packages with both library and executable in them -----------------------------------+---------------------------------------- Reporter: kr.angelov@… | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | -----------------------------------+---------------------------------------- If you have package which contains both a library and an executable then the dependencies for the compiler library are set to be the union of the dependencies for the executable and the library. For example with the GF package description: http://hackage.haskell.org/packages/archive/gf/3.1.6/gf.cabal 'ghc-pkg describe gf' will report: depends: Win32-2.2.0.1-f796bdb4f71914e9886090422be8f9cb array-0.3.0.0-dbdf73710a5bd9a534e8bcb2d8c8ee98 base-4.2.0.0-f9f9ffe572130b994c2080b74a5b4e68 bytestring-0.9.1.5-00c16473505de56926118ef2c791fff2 containers-0.3.0.0-409fe3b8f0dda25b98e03716d26be411 directory-1.0.1.0-57db95a03e1d1b3b8c63f3744fe9d297 filepath-1.1.0.3-ccf4622ce5a33fc941fb0fe1e5fa228c haskeline-0.6.2.2-1c1615561ccaeda54ae035ac05fbd790 mtl-1.1.0.2-23ca4de7c573fd4df309067199a40634 old-time-1.0.0.3-31e98cd52d90f145132096c2ac27b2bb pretty-1.0.1.1-2bfa34c699efff7eed4d6297a2dac12d process-1.0.1.2-defcecf2341a38cef42864b527e668bb random-1.0.0.2-156803737564049405b3380fdb96ac75 while the real library dependencies are only base, array, containers, bytestring and random. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/664> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Re: [Hackage] #137: setup sdist places implementation-dependent preprocessor output in the source bundle
by Hackage 21 Apr '10

21 Apr '10

#137: setup sdist places implementation-dependent preprocessor output in the source bundle ----------------------------------+----------------------------------------- Reporter: ross@… | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.4.2 Platform: Linux | ----------------------------------+----------------------------------------- Comment(by dankna): Attached, please find three patches for Cabal and one for Cabal-Install, in "darcs send" format. Also find a change to Happy, in the form of an entire Setup.lhs file to replace the corresponding file in Happy-1.18.4 (I guess I must not have been able to find the original repo for Happy - I can prepare a diff if you find that easier). These implement the stuff we talked about with regard to preprocessor output. Hopefully you'll like the way I did it. I'm afraid it's only easy for me to test with ghc, but it /should/ support all compilers, since I did make appropriate changes to all of their backends. If this is a problem I can try to get the others set up, but I hoped you might already be set for that and able to do it more quickly than I could. There are three main pieces to the patch, as the commit messages will explain. Briefly, the first piece simply redirects the output, the second piece makes sure the output is included in the sdist tarball, and the third piece adds a user hook to implement the subdirectory-naming policy we discussed. With the redirection of the output, I found that by doing it at the proper layer it wasn't necessary to add any new code to compare timestamps; the existing codepath appeared to handle it. This could use more testing; I used Happy as my test case. With the inclusion in sdist, I added a new parameter to prepareTree, which necessitated the change to Cabal-Install. As I explained in a comment somewhere, it includes ALL immediate subdirectories of preprocessed/, but within those, ONLY the files that have names which could have been generated by a known preprocessor from one of the included source files. With the subdirectory-naming, I added a new user hook that implements the concept of "specializing" the preprocessed output on a set of variables. Rather than defining a new vocabulary of variables which would then become maintenance overhead, I reused PathTemplateVariable for this purpose. It constructs a subdirectory name as a canonical representation of the set of variables specialized on, with their values. It uses URL-escaping for characters that we can't use for various reasons. I also made a trivial change to Happy's Setup.lhs, to test the specialization feature. I've included that one too; once the Cabal changes are released, either you or I can submit it to the Happy maintainer for inclusion there. It doesn't actually implement using Happy's --ghc option; it merely specializes the build properly, outputting into "compiler=ghc-6.blahblahblah" if the compiler is GHC or into "generic" otherwise. It does this by installing a preprocesserSpecialization hook which looks at the LocalBuildInfo it's given, checks the compiler flavor therein, and returns [CompilerVar] or [] as appropriate. Hopefully this is a sufficiently general capability for the use-cases that exist in the wild. As always, see the source for more details. I tried to follow your coding style as I understood it; in particular when I needed to add imports I enumerated each symbol used. I also tried to comment everything of any importance. I'll be interested in your feedback on how well I managed. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/137#comment:10> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #648: Cabal incorrectly reports missing C library IL
by Hackage 21 Apr '10

21 Apr '10

#648: Cabal incorrectly reports missing C library IL ----------------------------+----------------------------------------------- Reporter: GregoryWeber | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ----------------------------+----------------------------------------------- Changes (by duncan): * owner: kmcallister => * status: assigned => new Comment: The more common problem reported in #532 is now fixed. The specific instance of the problem here is with libraries. The linking failing usually but not always means the library is missing. As in this case it can be that dependent C libs (eg pthread) have not been listed. The error message for the linking failing case should be adjusted similarly to the header check to indicate it may be bad, and to re-run with -v3 for the full linker error. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/648#comment:5> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #342: Allow automatic resolving of conditionals on more than just build-depends
by Hackage 21 Apr '10

21 Apr '10

#342: Allow automatic resolving of conditionals on more than just build-depends -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: 6.8.2 Platform: | -----------------------------+---------------------------------------------- Changes (by duncan): * cc: Axel.Simon@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/342#comment:7> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #662: Use flags to figure out working pkg-config constraints.
by Hackage 21 Apr '10

21 Apr '10

#662: Use flags to figure out working pkg-config constraints. ----------------------------+----------------------------------------------- Reporter: Axel Simon | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Currently, cabal tries all possible flag assignments to fulfill the requirements on Haskell packages. For Gtk2Hs and probably other wrappers around C libraries it would be great to extend this functionality to pkg- config dependencies. They follow very similar convention when it comes to versioning but currently the users of my Setup.hs script need to specify the right flag combination to make configuring succeed. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/662> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

patch applied (cabal): Do not pass the CopyFlags to the per-compiler installLib/Exe functions
by Duncan Coutts 20 Apr '10

20 Apr '10

Tue Apr 20 15:58:30 PDT 2010 Duncan Coutts <duncan(a)haskell.org> * Do not pass the CopyFlags to the per-compiler installLib/Exe functions M ./Distribution/Simple/GHC.hs -10 +6 M ./Distribution/Simple/Install.hs -5 +5 M ./Distribution/Simple/LHC.hs -9 +5 M ./Distribution/Simple/UHC.hs -4 +2 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0