June 2008 - cabal-devel

[Hackage] #305: Link to Cabal 1.2.3.0 is dead
by Hackage 24 Jun '08

24 Jun '08

#305: Link to Cabal 1.2.3.0 is dead ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.2.3.0 Severity: minor | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.2.2 Platform: | ----------------------------------+----------------------------------------- The link on http://haskell.org/cabal/download.html to version 1.2.3.0 is dead, it should be http://haskell.org/cabal/release/cabal-1.2.3.0/cabal-1.2.3.0.tar.gz -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/305> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #258: case confusion - cabal vs Cabal
by Hackage 23 Jun '08

23 Jun '08

#258: case confusion - cabal vs Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- The darcs repo for Cabal is at darcs.haskell.org:/home/darcs/cabal yet it contains a file Cabal.cabal, which indeed claims that the name of the package is Cabal. This confusion of letter case is causing problems for me. Can we agree that Cabal is capitalised, and rename the repo dir? That seems like the simplest way to achieve consistency. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/258> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #265: Cabal field stability not useful
by Hackage 22 Jun '08

22 Jun '08

#265: Cabal field stability not useful ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- As it stands, the 'stability:' field isn't very useful. Hardly anyone uses it, and even if someone does, it does minimal good, since it's just an arbitrary string. I propose it be changed into an enumerated type, like license: is. That way we could do things like have cabal-install warn when installing unstable, add view filters to Hackage, and so on. This is all stuff that'd be pretty ad-hoc if done on whatever strings package authors were writing. Now, what should the entries be? Ideally, we'd like to be able to say a couple things. We'd like to say that a release is Stable, or Unstable. For example, HaXml's most recent package on Hackage is Unstable, and that's why Goerzen's Hpodder uses an older, Stable, version of HaXml. But we'd also like to express not just stability, but feature-completeness - Alpha, Beta, Release. It's perfectly sensible to have a piece of software which is a Stable Alpha; early XMonads were very stable (I was using it from the first public repo patches, and it only ever crashed a handful of times, less than StumpWM). And equally I'd suggest you could have Unstable Betas. Most cabal files I've seen using stability: seem to use 'Stable', 'Unstable', 'Experimental', 'Alpha', or 'Beta'. (Although GTK2HS seems to be using 'Stability: provisional'). So perhaps one could make the stability field accept 0-2 entries: one from Stable/Unstable, and one from Experimental/Alpha/Beta/Release. -- gwern -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/265> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

Re: [Hackage] #137: setup sdist places implementation-dependent preprocessor output in the source bundle
by Hackage 20 Jun '08

20 Jun '08

#137: setup sdist places implementation-dependent preprocessor output in the source bundle ----------------------------------+----------------------------------------- Reporter: ross(a)soi.city.ac.uk | Owner: Type: defect | Status: new Priority: high | Milestone: Cabal-1.6 Component: Cabal library | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------------+----------------------------------------- Comment (by igloo): Incidentally, `include/HsGLUT.h` is in `extra-tmp-files`; should Cabal look at that when deciding what to put in the sdist? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/137#comment:8> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Relocable packages with library
by Krasimir Angelov 20 Jun '08

20 Jun '08

Hi, I have a package that contains one library, one executable and a number of data files. If the package contains only executables then the generated Paths_<pkgid>.hs on Windows uses the executable location in order to calculate the datadir, libdir, etc directories. This is useful feature if someone wants relocable binary distributions. If the package has library then these directories are fixed. The initial reason was that many executables might be linked to this library and they should share the same data files. This usually makes sense but sometimes it is also useful to have library with relocable data directory. In this case it will be relative to the location where the executable linked with it is installed. If several executables are linked with the same library then they can be installed in one directory and they still will be able to share the common data directory. This is currently the common situation, since all executables are installed in "c:\Program Files\Haskell\bin". I already experienced the problem with haddock-2.0 where the precompiled binary expects that some files are installed in "C:\builds\haddock-2\install\haddock-2.0.0.0\html" which is wrong of course. Now I strike the same problem with another package. I propose to either add flag to configure saying that directories in Paths_<pkgid>.hs should be relative or to make them relative in all cases. What do you think? Regards, Krasimir

2 2

Cabal-1.4: library-dirs and include-dirs missing from package description after install
by Alistair Bayley 20 Jun '08

20 Jun '08

I'm trying to build and install Takusen 0.8.2 with a new .cabal and Setup, using Cabal-1.4.0.0. The Setup program writes out an updated Takusen.buildinfo (below) from the postConf hook. However, the library-dirs and include-dirs fields are not included in the package description when installed. Any ideas as to what I'm doing wrong? Alistair --------------- Takusen.buildinfo --------------------- buildable: True build-tools: odbcconf -any, sqlplus -any, pg_config -any, sqlite3 -any cpp-options: cc-options: ld-options: --enable-stdcall-fixup pkgconfig-depends: frameworks: c-sources: extensions: CPP extra-libraries: odbc32 oci pq sqlite3 extra-lib-dirs: "C:\\Program Files\\sqlite3\\" C:/PROGRA~1/POSTGR~1/8.1/lib C:\oracle\product\10.2.0\client_1\bin includes: install-includes: include-dirs: "C:\\Program Files\\sqlite3\\" C:/PROGRA~1/POSTGR~1/8.1/include C:/PROGRA~1/POSTGR~1/8.1/include/server C:\oracle\product\10.2.0\client_1\oci\include hs-source-dirs: . other-modules: Database.InternalEnumerator ghc-prof-options: -prof -auto-all ghc-shared-options: -prof -auto-all ghc-options: hugs-options: nhc98-options: jhc-options: ------------------------------------------------------------------------ ghc-pkg describe Takusen-0.8.2: name: Takusen version: 0.8.2 license: BSD3 copyright: 2003-2008, Alistair Bayley, Oleg Kiselyov maintainer: alistair(a)abayley.org, oleg(a)pobox.com stability: experimental homepage: http://darcs.haskell.org/takusen package-url: http://darcs.haskell.org/takusen description: Takusen is a DBMS access library. ... <trimmed> category: Database author: Alistair Bayley, Oleg Kiselyov exposed: True exposed-modules: Database.ODBC.Enumerator Database.ODBC.OdbcFunctions Database.Oracle.Enumerator Database.Oracle.OCIConstants Database.Oracle.OCIFunctions Database.PostgreSQL.Enumerator Database.PostgreSQL.PGFunctions Database.Sqlite.Enumerator Database.Sqlite.SqliteFunctions Database.Enumerator Database.Util Database.Stub.Enumerator Control.Exception.MonadIO Foreign.C.UTF8 hidden-modules: Database.InternalEnumerator import-dirs: "C:\\Program Files\\Haskell\\Takusen-0.8.2\\ghc-6.8.1" library-dirs: "C:\\Program Files\\Haskell\\Takusen-0.8.2\\ghc-6.8.1" hs-libraries: HSTakusen-0.8.2 extra-libraries: odbc32 oci pq sqlite3 extra-ghci-libraries: include-dirs: includes: depends: base-3.0.0.0 mtl-1.1.0.0 old-time-1.0.0.0 time-1.1.2.0 hugs-options: cc-options: ld-options: --enable-stdcall-fixup framework-dirs: frameworks: haddock-interfaces: "C:\\Program Files\\Haskell\\doc\\Takusen-0.8.2\\html\\Takusen.haddock" haddock-html: "C:\\Program Files\\Haskell\\doc\\Takusen-0.8.2\\html"

2 5

[Hackage] #298: Local build logs
by Hackage 19 Jun '08

19 Jun '08

#298: Local build logs ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ As a user of cabal-install, I would like build logs which are organized slightly differently than the logs which are to be used for reporting back to hackage. In particular: * The local build log should have accurate timestamps; for anonymity purposes the reporting logs should not have timestamps. * The local build log should not partition logs per-server. * The local build log should also track things installed from source using cabal-install which may have been obtained somewhere other than a hackage server. Since the different types of logs have different purposes, it makes sense to add separate local logging capabilities (thus duplicating some information) rather than trying to shoehorn both purposes into the same log format. A simple way to start would be to copy Hackage/Reporting.hs to Hackage/Logging.hs and tweak. Later, things could be refactored to pull out common code. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/298> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

patch applied (cabal-install): Add initial build logging, based on reporting code
by Duncan Coutts 19 Jun '08

19 Jun '08

Thu Jun 19 16:33:41 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add initial build logging, based on reporting code M ./Hackage/Config.hs +1 M ./Hackage/Install.hs +3 A ./Hackage/Logging.hs View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080619233341-adfee-…

1 0

patch applied (cabal-install): Fix the upload command message about the location of the config file
by Duncan Coutts 19 Jun '08

19 Jun '08

Wed Jun 18 13:17:37 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Fix the upload command message about the location of the config file M ./Hackage/Setup.hs -2 +1 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080618201737-adfee-…

1 0

patch applied (cabal-branches/cabal-1.4): Include trailing newline in hscolour command description
by Duncan Coutts 19 Jun '08

19 Jun '08

Thu Jun 19 15:09:40 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Include trailing newline in hscolour command description M ./Distribution/Simple/Setup.hs -1 +1 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008061922…

1 0