September 2007 - cabal-devel

[Hackage] #158: if os(windows) does not work
by Hackage 25 Sep '07

25 Sep '07

#158: if os(windows) does not work ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: high | Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.4.2 Platform: Linux | ------------------------------+--------------------------------------------- The {{{os}}} condition currently uses the {{{System.Info.os :: String}}} to check if we're on the OS specified. This is bad and wrong since in GHC at least on Windows this string is {{{"mingw32"}}}. For configurations it's ok if this works: {{{ if os(mingw32) blah }}} but it's essential that this works: {{{ if os(windows) blah }}} At a bare minimum we should add an alias system, such that we can specify {{{windows}}} and {{{solaris}}} rather than the cryptic {{{mingw32}}} and {{{solaris2}}}. I suggest that comparisons also be case insensetive. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/158> Hackage <http://example.com/> My example project

1 1

patch applied (cabal): Be more fuzzy with os, arch and impl matching in conditions. Fixes bug #158.
by Duncan Coutts 25 Sep '07

25 Sep '07

Tue Sep 25 06:26:08 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * Be more fuzzy with os, arch and impl matching in conditions. Fixes bug #158. Do all the comparisons case insensitively and add some OS aliases so that if os(windows) works if the System.Info.os is actually "mingw32". M ./Distribution/Configuration.hs -3 +11

1 0

build-depends in old-style package descriptions
by Ross Paterson 24 Sep '07

24 Sep '07

The build-depends field has been moved from the package level to the individual library and executable components. (And the new build-tools and pkgconfig-depends fields are similarly attached to components.) I'm not sure whether this is a good idea, but more specifically I came across this in the parser for old-style package descriptions in Distribution.PackageDescription: -- The 'build-depends' field was global so far. Now it's -- supported in each section. -- XXX: we actially have two options here -- (1) put all dependencies into the library section, if the -- library section would be empty, mark it as not buildable -- (2) duplicate all dependencies in each section, libraries -- and executables -- Right now we go with (1) Surely (1) is just wrong. Is there any reason not to do (2)?

2 6

[Hackage] #157: Haddock command fails when dependent documentation is not installed
by Hackage 24 Sep '07

24 Sep '07

#157: Haddock command fails when dependent documentation is not installed ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.4.2 Platform: Linux | ------------------------------+--------------------------------------------- Cabal checks with ghc-pkg for where the .haddock file of dependent packages should be. However even though ghc-pkg says it's there, it very often isn't there. In this case we still ask haddock to use it, and haddock justifiably complains. Cabal should check that the .haddock file actually exists. If it does not, Cabal should warn that links to this dependent package will not be generated because the docs for this dependent package are not installed. It should then not tell haddock to use that package. Current behavior: {{ $ runghc Setup.lhs haddock Preprocessing library bytestring-0.9... Running Haddock for bytestring-0.9... haddock: /usr/share/doc/ghc-6.4.2/html/libraries/base/base.haddock: openBinaryFile: does not exist (No such file or directory) }} Desired behavior: {{ $ runghc Setup.lhs haddock Preprocessing library bytestring-0.9... Running Haddock for bytestring-0.9... Warning: Documentation for package base is not installed. No links will be generated. Documentation created: dist/doc/html/bytestring/index.html }} Or something like that, I'm sure someone can think of a clear friendly warning message This should be an easy bug for some new Cabal hacker to have a go at. It should just require modifying makeReadInterface in the Distribution.Simple.Haddock module. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/157> Hackage <http://example.com/> My example project

1 1

Re: [Hackage] #14: allow preprocessing for Main modules
by Hackage 24 Sep '07

24 Sep '07

#14: allow preprocessing for Main modules ---------------------+------------------------------------------------------ Reporter: ijones | Owner: duncan Type: defect | Status: closed Priority: high | Milestone: Cabal-1.2 Component: Cabal | Version: 1.1.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy Ghcversion: 6.2.1 | Platform: Linux ---------------------+------------------------------------------------------ Changes (by duncan): * resolution: => fixed * status: assigned => closed -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/14> Hackage <http://example.com/> My example project

1 0

patch applied (cabal): Don't generate links when dependent docs not installed. Fixes bug #157.
by Duncan Coutts 24 Sep '07

24 Sep '07

Mon Sep 24 07:25:20 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * Don't generate links when dependent docs not installed. Fixes bug #157. Generates a warning rather than failing as before. M ./Distribution/Simple/Haddock.hs -6 +11

1 0

patch applied (cabal): Fix warnings
by Duncan Coutts 24 Sep '07

24 Sep '07

Sun Sep 23 05:29:21 PDT 2007 Ian Lynagh <igloo(a)earth.li> * Fix warnings M ./Distribution/Simple.hs -2 +1

1 0

patch applied (cabal-branches/cabal-1.2): Fix warnings
by Ian Lynagh 23 Sep '07

23 Sep '07

Sun Sep 23 05:29:21 PDT 2007 Ian Lynagh <igloo(a)earth.li> * Fix warnings M ./Distribution/Simple.hs -2 +1

1 0

cabal dependencies patch
by Peter Gavin 22 Sep '07

22 Sep '07

Duncan requested that I post a more up-to-date version of the dependencies based build for the upcoming Hackathon. It still needs some work, but the bright side is that it's a drop-in replacement for the current build system. I guess what still needs to be done is: * Hugs, NHC, etc. I don't really use anything but GHC. * Executables - I'm thinking about writing out an in-place config file and just using ghc --make -hide-all-packages -package-conf ... -package ... * Standardize some kind of structure for the build directories. It's currently pretty ad-hoc. * Documentation - I meant to do this but I've been pretty busy the last couple weeks. The code is pretty straightforward, though. * Finally, it needs to eventually be better integrated with the rest of cabal. Since I decided to do it without modifying any of the other cabal sources, I end up duplicating a lot of code in places. Pete

1 0

Re: [Hackage] #14: allow preprocessing for Main modules
by Hackage 22 Sep '07

22 Sep '07

#14: allow preprocessing for Main modules ---------------------+------------------------------------------------------ Reporter: ijones | Owner: duncan Type: defect | Status: assigned Priority: high | Milestone: Cabal-1.2 Component: Cabal | Version: 1.1.3 Severity: normal | Resolution: Keywords: | Difficulty: easy Ghcversion: 6.2.1 | Platform: Linux ---------------------+------------------------------------------------------ Changes (by duncan): * ghcversion: => 6.2.1 * platform: => Linux * status: new => assigned * owner: ijones => duncan Comment: This second patch has been committed to Cabal HEAD. Perhaps someone can test and confirm this as I've only tested one small example. One actually needs to say: {{{ Executable: Foo Main-is: Main.hs }}} and it'll look for any suitable file that can be pre-processed into {{{Main.hs}}}, like {{{Main.hsc}}} for example. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/14> Hackage <http://example.com/> My example project

1 0