- cabal-devel - Haskell.org

cabal-make almost ready
by Conal Elliott 25 Jan '07

25 Jan '07

I've been working on some haddock-related Cabal tweaks and a "make" include file called "cabal-make", which manages syntax coloring (vis hscolour) with links from the haddock docs, web-based links to other libraries, and wiki-based user comments. It's ready to release for others' use except for one problem (as mentioned below). The --haddock-args flag ends up turning my forward slashes into backslashes (on my WinXP machine), so all of the web links are broken. I'd appreciate suggestions about this problem. You can find an example doc generated by cabal-make (a previous implementation that didn't quite fit cabal) at http://darcs.haskell.org/packages/TV/doc/html/Interface-TV-Output.html . Suggestions welcome. - Conal ---------- Forwarded message ---------- From: Conal Elliott <conal(a)conal.net> Date: Jan 19, 2007 5:18 PM Subject: Re: [Conal Elliott] Re: getting cabal to pass more info to haddock To: Isaac Jones <ijones(a)syntaxpolice.org> Cc: cabal-devel <cabal-devel(a)haskell.org> Hi Isaac. Now I see why the patch file was empty. And after some head-scratching about your note below, I'm glad the patch was empty. I hadn't noticed the --xxx-args flags for configure, and instead added a new haddock flag. Giving a flag to configure makes a lot more sense. So now I have just a new pair of flags enable-use-packages & disable-use-packages, which control whether haddock gets automatically-generated --use-package flags. My makefile are now performing this sort of incantation: ./setup configure --disable-use-packages --haddock-args="\ --read-interface=http://haskell.org/ghc/docs/latest/html/libraries/base,c:/ghc/ghc-6.6/doc/html/libraries/base/base.haddock \ --read-interface=http://haskell.org/ghc/docs/latest/html/libraries/mtl,c:/ghc/ghc-6.6/doc/html/libraries/mtl/mtl.haddock\ " The only problem is --haddock-args ends up turning my forward slashes into backslashes, so all of the web links are broken. Any advice? - Conal On 1/17/07, Isaac Jones <ijones(a)syntaxpolice.org > wrote: > > Hi Conel. Thanks for this! It sounds like the ideas from your > makefile could be used for Hackage for generating nice Haddock :) > > There is a general meachanism for adding --foo-args for each Program > that cabal knows about; can you use this meachanism to add --foo-arg > as well, instead of special-casing for haddock? > > If you do that, can you make the help output not suck? Currently it > does something like this: > > --ar-args=ARGS give the args to ar > --haddock-args=ARGS give the args to haddock > --ld-args=ARGS give the args to ld > --pfesetup-args=ARGS give the args to pfesetup > --ranlib-args=ARGS give the args to ranlib > --runghc-args=ARGS give the args to runghc > --runhugs-args=ARGS give the args to runhugs > --tar-args=ARGS give the args to tar > > it would be nice to concerve lines with sometthing like this: > > --ar-arg=ARG --ar-args=ARGS give the arg or args to ar > --haddock-arg=ARG --haddock-args=ARGS give the arg or args to haddock > etc > > The patch you sent seemed like an empty file to me. Maybe I'm just > being nihilistic ;) > > peace, > > isaac >

2 3

debugging support - multidimensional package selection - excursion
by Marc Weber 22 Jan '07

22 Jan '07

If we want to add debugging support consider a packagetree like this: a - b ( depends on b and c, c on d and e) | + - c - d | + - e its obvious if I want to have a profiling lib a I need b..e compiled with -prof, too But if I want to build it with debugging messages what about b,c,d,e They might have been compiled with debugging support but don't have to. Consider the scenario a,c,d beeing compiled as debugging, but I'm also working on another project which doesn't need c as debugging. This would mean I need two versions of c (with debugging enabled and disabled) -> naming conflict.. This could be solved by introducing aliases. eg ./cabal-install d as d-debug --enable-debug ./cabal-install c as c-debug --enable-debug --with d-debug as d ./cabal-install a --with c-debug as c and I would be done This way you can even install different developement versions of your libraries .. (sure testing should be done with HUnit or qpuickcheck not with final applications ..) Of course this is only useful for testing not for distribution ... I don't think this would make things much more complicated but would make the system much more flexible .. Wait.. This would mean: you have a package id and you have flags to select the right version a flag is a) version b) configure options such as profile, debug, use lib a instead of b, ... But this would mean when deciding which libraries to install by default: instance Default Stability -- stable wins instance Default Version -- greater wins instance Default Debug -- no debug wins instance Default Profiling -- no profiling wins if not specified else. This leads me to the question: Is it enough to identify a package by (name/id) and version? I think a more dimensional way would be useful Thus adding another dimension (os / instance Default Cross-Compilation-Target -- defaults to no cross-compilation an easy extension.. And this would make it easy to manage libs for your os, that of your neighbour, your microcontroller, .... Of course ghc-pkg list will no longer show Lib (version=2.0, debug=on, profiling=on, target-architecture=x64) rather than Lib-2.0 Some of those flags would be backtracking (architecture, profiling) others not (debug = on) Fortunately you don't have the design of ghc to test this as you can use aliases .. Any comments? Is this all nonsense ? Marc

2 1

Hackage plan
by Simon Marlow 19 Jan '07

19 Jan '07

While at the Hackathon, Björn, Ross, Ian, myself and others collected some ideas for directions in which Hackage (the web interface primarily, as opposed to cabal-install) should develop. I put everything in this wiki page: http://hackage.haskell.org/trac/hackage/wiki/HackageToDo It's quite rough, but I think it's a good starting point. I suggest we do some more brainstorming and flesh out that page, and then extract a "plan" for how to proceed. Of course the plan shouldn't be single threaded - there will be tasks that can be tackled independently, but there will necessarily be dependencies. For example there are lots of things that can't be done until we have automatic package building of some kind. We should have some milestones, focussed towards getting to a point that the system is usable quickly, and adding the bells & whistles later. First off we have two web interfaces: Ross's and Lemmih's. Ross's lets you upload. In due course having multiple web interfaces is certainly a possibility, but for now we need to focus our limited efforts in one place. I suggest Ross's inteface, being the closest to being usable, is the right place to start. Ross - is it possible to write some simple instructions describing how to set up the web interface on a local machine for development/testing? Cheers, Simon

5 4

darcs patch: Add preliminary support for haddock-ghc (and 1 more)
by davve＠dtek.chalmers.se 17 Jan '07

17 Jan '07

Fri Sep 15 21:29:49 CEST 2006 davve(a)dtek.chalmers.se * Add preliminary support for haddock-ghc Fri Jan 5 22:22:24 CET 2007 davve(a)dtek.chalmers.se * Add -D__HADDOCK__ to haddock-ghc

3 2

Re: haddock suggestion -- %{FILE}
by Conal Elliott 17 Jan '07

17 Jan '07

I did get working again by commenting out the "-optP-P" that gets passed to Haddock. Now I want to eliminate my local mod. I could easily add a another Cabal Haddock flag that says to omit the -optP-P, but I prefer the solution of checking the Haddock version number, since it would always do the right thing with no intervention. Can anyone give me hints about how to do the version check? - Conal On 1/9/07, Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> wrote: > > On Tue, 2007-01-09 at 09:32 -0800, Conal Elliott wrote: > > The only pre-processing is what's caused by using the cabal directive > > "Extensions: CPP". > > > Fiddling with flags, I see that -optP-P is the culprit. Removing it: > > > > bash-3.2$ ghc -E -cpp -o z src/Graphics/UI/TV/Input.hs > > -Dmingw32_BUILD_OS -Dmingw32_HOST_OS -Di386_BUILD_ARCH > > -Di386_HOST_ARCH -D__GLASGOW_HASKELL__=606 -D__HADDOCK__; head -3 z > > # 1 "src/Graphics/UI/TV/Input.hs" > > # 1 "<built-in>" > > # 1 "<command line>" > > bash-3.2$ > > > Any ideas? - Conal > > So for a quick hack, modify Cabal to unconditionally omit -optP-P and > see if that makes all your links come out right. > > Probably the right thing to do however is to have Cabal use the -optP-P > option only when we're using haddock-0.7 or older (otherwise haddock-0.7 > users will get a lexical error when haddock encounters the C line > pragmas). > > I think at the moment Cabal doesn't check haddock's version number at > all. So that's something to look at if you or anyone else want to come > up with a patch for this. > > > Duncan > >

2 1

new Darcs-Repository field?
by Ross Paterson 15 Jan '07

15 Jan '07

Björn Bringert suggested that the Hackage page for a package should include a link to the Darcs repo (if any, but who uses anything else?) and maybe some darcs integration such as changelogs and the like. To make this work, we'd need a URL-valued Darcs-Repository field in the package description.

6 5

ghc requesting package version 1.1.7 but 0.1.7 is installed ?
by Marc Weber 15 Jan '07

15 Jan '07

$ ghc -o setup --make -package Cabal-0.1.7 setup.hs Linking setup ... ghc-6.5.20060917: unknown package: Cabal-1.1.7 I don't understand this. I've substituted Version 1.1.7 by 0.1.7 to get a low version which won't be used unless requested. This is the only Cabal package beeing installed. $ ghc-pkg describe Cabal shows name: Cabal version: 0.1.7 license: BSD3 ... Why is ghc requesting still 1.1.7? set | grep 1.1.7 doesn't list any interesting environment variable except of pwd and OLDPWD The Cabal which has been destributed with my ghc is verison 1.1.5.9.2 thus can't be the problem. Any suggestion is appreciated. Marc

2 1

Using Cabal for dependancies
by Neil Mitchell 15 Jan '07

15 Jan '07

Hi, The Yhc compiler depends on an increasingly large number of Cabal packages - mtl and FilePath at the moment, but soon thats likely to increase by at least 3. Cabal is not yet mature enough to compile Yhc, and fitting in a compile of bits with Cabal will be quite hard because of the existing complexity in Scons. So what we'd really like to do is be able to call "cabal check-its-installed FilePath", which would return an appropriate exit code. If it wasn't installed then a darcs get, followed by a "cabal install-it-please" would be very handy. Does cabal-install provide the necessary bits for this? What is the result of installing a package that is already installed? How long til this kind of solution will be widely enough deployed that we can actually use it? Does anyone else have any other suggestions? Thanks Neil

2 3

Re: Multiple .cabal Files
by Henning Thielemann 13 Jan '07

13 Jan '07

Since the .installed-pkg-config and .setup-config files depend on the configure procedure and on the machine - shouldn't they be placed in 'dist', even more in a machine dependent sub-directory?

1 0

hackage projects for Hackathon
by Isaac Jones 09 Jan '07

09 Jan '07

Greetings! Many of you will be at the Hackathon tomorrow: http://www.haskell.org/haskellwiki/Hac_2007 I just did a brain-dump of what I think needs to get done to make cabal-install and hackage a reality. Much of the Hacking is already done and in good shape, but there are probably lots of little things to do, and there is work that needs to happen in order to gain adoption from the community. Here's my brain dump: http://hackage.haskell.org/trac/hackage/ticket/107 Of course, I'm not the only one with ideas, and others might have a lot of good ideas about what needs to be done. Above all, make it yours! Linked from the Hac 07 project page: http://www.haskell.org/haskellwiki/Hac_2007/Projects I'm going to try to be on IRC for some of the event, although the time of day isn't the best for me (since it starts at 2AM my time) :) peace, isaac

1 0