September 2007 - cabal-devel

Re: [Haskell-cafe] RE: Definition of the Haskell standard library
by Duncan Coutts 01 Sep '07

01 Sep '07

On Sat, 2007-09-01 at 18:47 +0200, Sven Panne wrote: > On Tuesday 31 July 2007 19:39, Duncan Coutts wrote: > > [...] > > The docs for those packages would be available for packages installed > > via cabal (assuming the user did the optional haddock step) and would > > link to each other. > > Well, on a normal Linux distro a user should *never* have to call cabal (or > any of its cousins) directly, the distro's package manager should be the used > instead. On an e.g. RPM system, the .spec file would use Cabal to e.g. > (un-)register a package, because RPM has to know what is installed, which > other packages are prerequisites, how to cleanly uninstall, etc. IMHO Cabal > should not try to mirror a full-fledged package system, simply because on > every (non-Windows ;-) platform there are tons of native tools for this > purpose, and Cabal is not "in the driver's seat" when it comes to SW > installation. I think it's inevitable that there will always be a mixture of packages that are managed by the system package manager and ones that are too insignificant to be packaged by the distro. So cabal-install should cooperate with the system package manager somehow. Another strategy would be to have tools that the users can use to generate system packages from cabal packages and then install those via the system package manager. We already have such tools for rpm and gentoo ebuilds. Again, these would be for the case of less significant package that the distro does not package itself. For example, gentoo has a tool that can be used to install perl CPAN packages via the system package manager, since there are many 1000's of CPAN packages and only a few hundred of those are included in the main portage collection. There are other cases not covered by system package managers, like unprivileged user installations under $HOME. > > The problem with generating one of those is what manages it? What > > package would it belong to etc. > > Of course we are not the first project to face this kind of problem: Texinfo > offers a central contents page as well. To maintain this page, it comes with [..] > A "install-haddock" tool would be the solution IMHO. That re-generates the index page, right. Perhaps haddock itself should be extended with this ability. All it should need to do is read all the .haddock files that ghc-pkg knows about and generate the index page from that. I assume the .haddock files contain enough information to do this, or it could be modified to include enough. Duncan

1 0

Re: patch applied (packages/regex-posix): Make setup script compile again after recent Cabal changes
by Duncan Coutts 01 Sep '07

01 Sep '07

On Sat, 2007-09-01 at 19:40 +0200, Sven Panne wrote: > On Saturday 01 September 2007 19:37, Duncan Coutts wrote: > > On Sat, 2007-09-01 at 04:56 -0700, Sven Panne wrote: > > > Sat Sep 1 04:55:36 PDT 2007 sven.panne(a)aedion.de > > > * Make setup script compile again after recent Cabal changes > > > > BTW, as far as I can see, this Setup.hs is no longer needed. If it read > > it correctly, all it does is implement a --ghc-option= flag. Cabal now > > does that itself --ghc-args= or --ghc=arg= > > I've just copied the Setup.lhs from regex-base, because that worked (and I am > currently not interested in the Cabal-API-of-the-day). Indeed, I recommend not putting any custom code in Setup.(l)hs unless it's absolutely essential. If we want to keep making improvements to Cabal's internal code and adding features we will inevitably have to continue making changes to the hooks api and other internal apis. At the moment the design of the hooks api is very fragile. Any change breaks all Setup.lhs programs. We've don't yet really know what the hooks api should look like, but we expect there will be some significant change in the next version. Hopefully we can come up with a design that is less fragile, for example using a Configure/Build monad rather than passing in lots of information a separate arguments, so that we could add more information without breaking existing hooks users. On the other hand we can make much stronger stability guarantees about the .cabal file format. > So probably all regex-*/Setup.lhs could be nuked... Or at least replaced with the default one that never breaks. Duncan

1 0

Re: [Hackage] #7: add --ghc-args and such to configure
by Hackage 01 Sep '07

01 Sep '07

#7: add --ghc-args and such to configure ----------------------------------+----------------------------------------- Reporter: ijones | Owner: ijones Type: enhancement | Status: closed Priority: high | Milestone: Cabal-1.2 Component: Cabal | Version: 1.1.3 Severity: normal | Resolution: fixed Keywords: | Ghcversion: 6.2.1 Difficulty: very easy (<1 hour) | Platform: Linux ----------------------------------+----------------------------------------- Changes (by duncan): * resolution: => fixed * status: reopened => closed Comment: Now documented. Also, I've added a {{{--prog-arg=}}} flag that behaves like {{{--configure-option=}}}. I've also made {{{--prog-args=}}} parse it's args more cleverly. Instead of using words which breaks on files with embedded spaces we now use a slightly more clever lexer that allows simple quoting with "" chars. eg: {{{ splitArgs "--foo=\"C:\Program Files\Bar\" --baz" = ["--foo=C:\Program Files\Bar", "--baz"] }}} so on the command line you'd use: {{{ ./setup configure --foo-args='--bar="some path with spaces"' }}} That is the " chars have to be passed to setup, so if necessary they have to be escaped in the shell invocation. The alternative of course is to use {{{ ./setup configure --foo-arg=--bar="some path with spaces" }}} again, assuming your shell parses {{{--foo-arg=--bar="some path with spaces"}}} into a single argument {{{--foo-arg=--bar=some path with spaces}}}. Oh the joys of shell quoting. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/7> Hackage <http://example.com/> My example project

1 0

patch applied (cabal): Add --prog-arg= and make --prog-args parse quotes
by Duncan Coutts 01 Sep '07

01 Sep '07

Sat Sep 1 10:17:42 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * Add --prog-arg= and make --prog-args parse quotes So this provides two ways of passing options that contain embeded spaces: --foo-args='--bar --baz="path with spaces in"' --foo-arg=--bar --foo-arg=--baz="path with spaces in" all args passed this way are collected in order. M ./Distribution/Simple/Setup.hs -27 +59 M ./doc/Cabal.xml -1 +28

1 0

patch applied (cabal): Don't use normalise when parsing configure arguments
by Duncan Coutts 01 Sep '07

01 Sep '07

Sat Sep 1 09:20:43 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * Don't use normalise when parsing configure arguments M ./Distribution/Simple/Setup.hs -4 +3

1 0

patch applied (cabal): Maintainer is now cabal-devel@haskell.org
by Ross Paterson 01 Sep '07

01 Sep '07

Sat Sep 1 07:09:21 PDT 2007 Ross Paterson <ross(a)soi.city.ac.uk> * Maintainer is now cabal-devel(a)haskell.org M ./Cabal.cabal -1 +1

1 0