- cabal-devel - Haskell.org

How to change -optc-O2 when compiling C files
by Roel van Dijk 31 Aug '09

31 Aug '09

Hello, I have cabal file which specifies some c-sources to compile together with the usual Haskell stuff. I noticed that cabal automatically passes -optc-O2 to GHC when compiling C files. If I specify some additional cc-options in my cabal file they just get prepended to the list of options passed to ghc. How do I get rid of the -optc-O2? With my current cc-options "-D_OPENMP -O3 -funroll-loops" GHC is invoked like this during a "cabal build": /usr/bin/ghc -Ilevmar-2.4 -package base-3.0.3.1 -optc-D_OPENMP -optc-O3 -optc-funroll-loops -optc-O2 -odir dist/build -c levmar-2.4/lm.c I don't know which -optc-O? will be picked by the C compiler. Normally -O2 is ok, but in this case I really want -O3. Thanks in advance, Roel van Dijk

1 0

[Hackage] #579: Wrong content type for web documentation
by Hackage 29 Aug '09

29 Aug '09

#579: Wrong content type for web documentation ----------------------------+----------------------------------------------- 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: | ----------------------------+----------------------------------------------- The http headers for http://www.haskell.org/cabal/release/cabal-latest/doc /users-guide/index.html return "Content-Type: text/html; charset=utf-8" however the documentation is in ISO-8859-1 format. The documentation source even has <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> but this doesn't override the content-type given by the HTTP headers in Firefox. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/579> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal): Use -R flags for hsc2hs wherever we use -L flags on ELF platforms.
by Duncan Coutts 29 Aug '09

29 Aug '09

Fri Aug 28 16:37:04 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Use -R flags for hsc2hs wherever we use -L flags on ELF platforms. Ignore-this: 357aa0d1865a1fe6bf37fb6f41e2c93a This fixes use of hsc2hs in cases where things like libgmp is not on the system's dynamic linker path. It's ok to use rpath in the case of hsc2hs because the linked programs are run immediately and never installed. M ./Distribution/Simple/PreProcess.hs -6 +14 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090828233704-adfee-5cbfdcba…

1 0

new hackage-server testing host
by Duncan Coutts 29 Aug '09

29 Aug '09

Hi Ross, (and other people interested in the hackage server) I've got ports 80 and 8080 open on the community sparc server and will be using it as a host for testing the new hackage-server implementation. http://sparky.haskell.org:8080/ One thing I noticed when importing data into it is that there are a small handful of packages that have no entry in the upload log. The new server expects to find such an entry so that it knows when the package was added. Ross, the packages in question I think are the ones that you uploaded after ghc-6.10 was released including base, containers etc. I'm guessing that the normal hackage upload rejected them with some QA complaints and that you had to add them by a manual process. I'm hoping we can just fix the upload log data by appending the appropriate lines to the upload log, eg by doing: echo 'Thu Apr 9 16:25:43 UTC 2009 RossPaterson base 4.1.0.0' >> log Does that seem reasonable? It means those lines would be out of order chronologically, but I don't think that is important. If you think this is reasonable then I'll get you the proper checked list of missing uploads. The other alternative might be for the current hackage server to let us download a tarball of all the package meta-data including the tag files, and we could adapt the new hackage-server to import from that format. Hopefully though we only need to take this approach if we start making much more use of the tag files. Duncan

2 2

patch applied (cabal-install): Fix calculation of paths in check for bindir symlink overwriting
by Duncan Coutts 29 Aug '09

29 Aug '09

Fri Aug 28 17:49:59 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Fix calculation of paths in check for bindir symlink overwriting Ignore-this: d4dd8e12c03d23ce935de94cedbda257 We were doing it wrong, but Linux realpath() C function was letting us get away with it. The Solaris realpath() is stricter. The new implementation is also simpler, relying on the fact that the canonicalizePath function will resolve symlinks. M ./Distribution/Client/InstallSymlink.hs -15 +14 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090829004959-adfee-…

1 0

[Hackage] #577: an executable and library differing in capitalization use the same build dir on case-insensitive filesystems
by Hackage 27 Aug '09

27 Aug '09

#577: an executable and library differing in capitalization use the same build dir on case-insensitive filesystems ----------------------------+----------------------------------------------- Reporter: simonmic | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Discussion from #darcs: {{{ [5:56pm] <Riastradh> While compiling the Darcs library, the build process creates a directory called $BUILDDIR/build/Darcs. While compiling the Darcs executable, it creates $BUILDDIR/build/darcs. On Mac OS X, these pathnames both name a common directory. [5:57pm] <kowey> yeah, that's mildly irritating [5:57pm] <kowey> I have to run dist/build/Darcs/darcs (tab-completion) [5:57pm] <Riastradh> Does this affect the output of the build? [5:57pm] <kowey> no apparent problems here [5:58pm] <Riastradh> OK. [5:58pm] <Riastradh> (You could, of course, create the directory with a lowercase name to begin with and then build.) [5:58pm] <Riastradh> (Also, some shells, such as zsh, will do case-insensitive completion.) [5:58pm] <kowey> I guess no other cabal package out there simultaneously has a library starting with Foo as a top level bit of namespace and an executable named foo [5:58pm] <gwern> Riastradh: bash of course can do case-insenistive completion if figured [5:58pm] <gwern> *configured [5:59pm] <gwern> kowey: xmonad? [5:59pm] <kowey> oh yeah! [5:59pm] <gwern> import XMonad.*... 'exec xmonad' [5:59pm] <gwern> and xmonad ain't the only example either [6:00pm] <gwern> yi, autoproc... anything doing the executable-library thing is likely to have that }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/577> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

patch applied (cabal): Add the ABI hash to the InstalledPackageId for inplace registrations too
by Simon Marlow 26 Aug '09

26 Aug '09

Wed Aug 26 08:51:57 PDT 2009 Simon Marlow <marlowsd(a)gmail.com> * Add the ABI hash to the InstalledPackageId for inplace registrations too Ignore-this: f10a1e90492a356a8ed8ed78fd056176 Previously, we just added a -inplace suffix, but this will cause problems when developing multiple packages inplace, and then installing them. Also, there was a round of refactoring: registerPackage now takes the InstalledPackageId as an argument, and generateRegistrationInfo is exposed for constructing it. This means that callers of registerPackage get to munge the InstalledPackageInfo before it is registered. M ./Distribution/Simple/Build.hs -2 +5 M ./Distribution/Simple/Register.hs -51 +35 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090826155157-12142-2eda3703…

1 0

patch applied (cabal): Bump minor version to 1.7.4
by Duncan Coutts 24 Aug '09

24 Aug '09

Sun Aug 23 18:04:33 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Bump minor version to 1.7.4 Ignore-this: 360111493090f2cf86a65dfa2bd41da0 due to recent API changes M ./Cabal.cabal -2 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090824010433-adfee-10d39062…

1 0

patch applied (cabal): Change finalizePackageDescription to take dep test function
by Duncan Coutts 24 Aug '09

24 Aug '09

Sat Aug 22 16:42:56 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Change finalizePackageDescription to take dep test function Ignore-this: 573c4d60e9c40f8814371a6c3a0b8c9 Ths is instead of taking a set of installed packages. This insulates us from the representation of the installed package set which is good since we now have several representations. It also opens the door to generalising the kinds of constraints we can handle. M ./Distribution/PackageDescription/Check.hs -6 +3 M ./Distribution/PackageDescription/Configuration.hs -17 +8 M ./Distribution/Simple/Configure.hs -4 +9 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090822234256-adfee-1ff0b59d…

1 0

patch applied (cabal): Add a HACKING file
by Duncan Coutts 24 Aug '09

24 Aug '09

Sat Aug 22 08:16:36 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Add a HACKING file Ignore-this: 222a83edbe3bf27574bfe51df7f109f0 Seems people do not know that the source guide exists. A ./HACKING View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090822151636-adfee-6c24647b…

1 0