August 2008 - cabal-devel

patch applied (cabal): Add auto-generated CPP macros for package version testing
by Simon Marlow 12 Aug '08

12 Aug '08

Mon Aug 11 10:30:16 PDT 2008 Simon Marlow <marlowsd(a)gmail.com> * Add auto-generated CPP macros for package version testing Now when using CPP you get MIN_VERSION_<package>(A,B,C) for each <package> in build-depends, which is true if the version of <package> in use is >= A.B.C, using the normal ordering on version numbers. This is done by auto-generating a header file dist/build/autogen/cabal_macros.h, and passing a -include flag when running CPP. M ./Distribution/Simple/Build.hs -2 +43 M ./Distribution/Simple/BuildPaths.hs +3 M ./Distribution/Simple/GHC.hs +2 M ./Distribution/Simple/PreProcess.hs -3 +9 M ./doc/Cabal.xml +41 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080811173016-12142-850c66ab…

1 0

patch applied (cabal): allow Cabal to use base-4
by Simon Marlow 12 Aug '08

12 Aug '08

Wed Aug 6 06:05:12 PDT 2008 Simon Marlow <marlowsd(a)gmail.com> * allow Cabal to use base-4 M ./Cabal.cabal -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080806130512-12142-d7e77cfa…

1 0

Re: [Hackage] #58: allow dev repo to be specified in cabal file
by Hackage 11 Aug '08

11 Aug '08

#58: allow dev repo to be specified in cabal file ----------------------------+----------------------------------------------- Reporter: ijones | Owner: Type: enhancement | Status: new Priority: high | Milestone: Cabal-1.6 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux ----------------------------+----------------------------------------------- Comment (by duncan): Replying to [comment:14 SamB]: > Would hackage then check that the contents of the tarball actually matches what's in the repository -- or simply make the tarball on its own? No, it would not check or generate tarballs. It'd be for other uses (manual or automatic) which wants the equivalent of a release in the source control system. What kind of uses? I'm sure there are several. How about looking at changes since a release, generating automatic changelogs. I'm sure other people can think of others. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/58#comment:15> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #58: allow dev repo to be specified in cabal file
by Hackage 11 Aug '08

11 Aug '08

#58: allow dev repo to be specified in cabal file ----------------------------+----------------------------------------------- Reporter: ijones | Owner: Type: enhancement | Status: new Priority: high | Milestone: Cabal-1.6 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux ----------------------------+----------------------------------------------- Comment (by SamB): Would hackage then check that the contents of the tarball actually matches what's in the repository -- or simply make the tarball on its own? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/58#comment:14> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal-install): Remove most warnings from BuildReports.Upload module
by Duncan Coutts 10 Aug '08

10 Aug '08

Sun Aug 10 14:17:05 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Remove most warnings from BuildReports.Upload module M ./Distribution/Client/BuildReports/Upload.hs -17 +4 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080810211705-adfee-…

1 0

patch applied (cabal): Make binary-dist do nothing in doc/Makefile, for now
by Ian Lynagh 10 Aug '08

10 Aug '08

Sat Aug 9 17:51:35 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Make binary-dist do nothing in doc/Makefile, for now M ./doc/Makefile +3 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080810005135-3fd76-1014870c…

1 0

patch applied (cabal): When running "Setup makefile", put "default: all" at the top of the Makefile
by Ian Lynagh 10 Aug '08

10 Aug '08

Sat Aug 9 14:11:48 PDT 2008 Ian Lynagh <igloo(a)earth.li> * When running "Setup makefile", put "default: all" at the top of the Makefile This make "make" work even if Makefile.local contains any targets. M ./Distribution/Simple/GHC/Makefile.hs -1 +1 M ./Distribution/Simple/GHC/Makefile.in +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080809211148-3fd76-67db83b6…

1 0

Re: [Hackage] #58: allow dev repo to be specified in cabal file
by Hackage 09 Aug '08

09 Aug '08

#58: allow dev repo to be specified in cabal file ----------------------------+----------------------------------------------- Reporter: ijones | Owner: Type: enhancement | Status: new Priority: high | Milestone: Cabal-1.6 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux ----------------------------+----------------------------------------------- Comment (by duncan): A similar proposal for the RPM packaging system: http://lwn.net/Articles/290300/ {{{ SCMType: {cvs|svn|git|hg|etc.} SCMRepo: <repo_url, complete spec for SCMs like git, would be cvs_root for cvs> SCMModule: <module name for repo types that need this, such as cvs> SCMTag: <tag representing exact source matching binary package> SCMBranch: <branch on which tag exists, allowing the installation of later sources from the same product line branch instead of exact sources of the installed package at the user's option> }}} Clearly we need to know which scm we're dealing with. But I think we also want to be able to refer to more specific things, in particular the 'HEAD' branch where new development happens and also the branch from which this release was made (if different) and optionally a tag for this specific release. Not all that information is required of course, but we should be able to specify it in a clear way. If the meaning is well defined then it allows us to to integration like rebuilding from the same branch+tag, following activity in a head repo (for info on the hackage website). If we don't give clear meanings it's almost useless, it can then only be used as a link for humans to follow and interpret. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/58#comment:13> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #58: allow dev repo to be specified in cabal file
by Hackage 09 Aug '08

09 Aug '08

#58: allow dev repo to be specified in cabal file ----------------------------+----------------------------------------------- Reporter: ijones | Owner: Type: enhancement | Status: new Priority: high | Milestone: Cabal-1.6 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by SamB): * summary: allow darcs repo to be specified in cabal file => allow dev repo to be specified in cabal file Old description: > add a field to cabal to specify a darcs repo. New description: Add a field to cabal file to specify a development repository. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/58#comment:12> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #58: allow darcs repo to be specified in cabal file
by Hackage 09 Aug '08

09 Aug '08

#58: allow darcs repo to be specified in cabal file ----------------------------+----------------------------------------------- Reporter: ijones | Owner: Type: enhancement | Status: new Priority: high | Milestone: Cabal-1.6 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by SamB): * cc: SamB (added) Comment: The SCM field is indeed rather vital, given that almost every distributed SCM supports fetching via HTTP in addition to SSH and any native protocol it may have. Anyway, it's simpler to implement that way. It would probably also be good to keep a registry of SCM names for the rare occasion where it isn't obvious what to put in the field -- arch comes to mind, and I guess there might be some confusion regarding mercurial/hg. Speaking of arch, some SCMs will very possibly require further parameters -- in arch's case, the branch to check out -- and others may benefit -- e.g. git could use a branch name, though {{{master}}} makes a reasonable default. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/58#comment:11> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0