January 2007 - cabal-devel

[Conal Elliott] Re: getting cabal to pass more info to haddock
by Isaac Jones 15 May '07

15 May '07

3 7

Why is there a cabal file at all?
by Marc Weber 12 Mar '07

12 Mar '07

Sorry for this stupid question put there must be reasons I don't know. I've been thinking a lot about packaging/ dependency handling etc the last days. Haskell is one of the most typesafe and expressive languages, right? Now we need a haskell compiler/ interpreter to run Setup.hs. So why not combine both and use some kind of cabal combinator library? I'll try to implement a prototype although knowing there are lots of people knowing how to do this better. module Setup where import CabalBuildProposal helloWorld = haskell-executable $ do setName "helloworld" sourceDir "src" $ mainIs "HelloWorld.hs" addDependencies = case stringOption "pretty_print_lib" of "A" : [LibVersionRange "A" "1.0 - 2.0"] "B" : [LibVersionRange "B" "1.0 - 2.0"] package = do setAuthor = "Marc Weber" addAtom helloWorld preprocess = defaultHaskellPreprocess build = preprocess >>= defaultHaskellBuild rpm = build >>= defaultRPM install = defaultHaskellInstall haddock = defaultHaddock targets = [ ("preprocessOnly", preprocess) , ("build", build ) , ("install", build >>= install) , ("rpm", rpm ) , ("haddock", preprocess >>= haddock) ] main = do handle package targets using preprocessors might be done in this way: addExposedModules $ map preprocessByCPP $ modulesByRegex "src/**/*.hs" I think you get the idea why this approach might be much more powerful? The package mantainers of ght2hs and wkhaskell have both trouble makeing their project work with cabal.. So why do we limit ourself using cabal files like the existing ones? I think you've noticed the line addDependencies = case stringOption "pretty_print_lib" of This should use the correct dependency if the option has already been set by cmdline or config file else ask the user or choose the first but noticing the user by printing a message like this: unset option "pretty_print_lib", defaulting to "A" preprocess should be passed all configuration options and return a list of source files, build should get the list of source file and return a list of executables which are installed by install straightforward, isn't it? Thus the right build/ install whatsoever step would be choosen not by defining hooks but by the haskell type system. This way the packaging system user can plug in his own implementation everywhere. Any ideas, comments? Anyone out there who wants to join and help implementing this idea? Marc

9 29

Cabal bug, times two and a half
by Bryan O'Sullivan 26 Jan '07

26 Jan '07

I tried reporting a Cabal bug via Trac, but I can't log in as guest/haskell. Alas. The bug is that "runhaskell Setup.hs --enable-library-profiling" doesn't imply -auto-all with ghc, so the profiled library contains only manual cost centres - in other words, it never shows up in profile output. The second bug is that the only way I can find to override or add compiler flags is to edit a .cabal file by hand. This makes it scarily easy to capture unintended flags when committing changes :-( <b

4 5

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 18 Jan '07

18 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